WINNER

D1.3 v1.0

IST-2003-507581 WINNER D1.3 version 1.0 Final usage scenarios

Contractual Date of Delivery to the CEC: 30/06/2005 Actual Date of Delivery to the CEC:

30/06/2005

Author(s):

Anne-Gaële Acx, Jukka Henriksson, Bernard Hunt, George T. Karetsos, Elias Tragos, Albena Mihovska, Sofoklis Kyriazakos, Lino Moretti, Juan Lara

Participant(s):

AAU, FTR&D, NTUA, NOK, PRL, SMC, TID

Workpackage:

WP1 - Scenarios

Estimated person months:

12 PM

Security:

Public

Nature:

R

Version:

1.0

Total number of pages:

80

Abstract:.

Keyword list: user scenarios, usage scenarios, service classes, business model, traffic models Disclaimer:

Page 1 (80)

Executive Summary The document is organized as follows: In chapter 1 an introduction of this deliverable is presented. In chapter 2 the general assumptions about usage scenarios arerecalled for a WINNER system, taking into account a deployment by the year 2015, in terms of coverage, service, scenarios, location, hardware and economics. The chapter 3 presents the achievement of the definition of a set of Service Classes. A qualitative mapping of these services into currently available systems is presented in order to identify to which extent proposed services are currently delivered today or not. Then, as response to requests from other work packages, a service classes grouping is proposed. In chapter 4 the final generic applications list and the most relevant scenario elements for each one is presented. Chapter 5 gives an initial analysis of WINNER system concept in view of the WP1 scenarios. Chapter 6 opens a new field: business and economic analysis. In chapter 7 the actual status of traffic models are presented. The majority of them are "evolved traffic models developed further from those presented in external relevant sources (IST-STRIKE project): browsing (internet), conversational voice, video streaming and audio streaming. Other traffic models are been developed within WP1 as the file transfer model and interactive activities (gaming, control). The most relevant conclusions are presented in chapter 8.

WINNER

D1.3 v1.0

Authors Partner

Name

Phone / Fax / e-mail

FTR&D

Anne-Gaële Acx

Phone: +33 1 45 29 69 64 Fax: +33 1 45 29 41 94 e-mail: [email protected]

NOK

Jukka Henriksson

Phone: +358 (0)7180 36578 Fax: +358 (0)7180 36856 e-mail: [email protected]

PRL

Bernard Hunt

Phone: +44 (0)1293 815055 Fax: +44 (0)1293 815024 e-mail: [email protected]

NTUA

George T. Karetsos

Phone: +30 21 0 7721511 Fax: +30 21 0 7722534 e-mail: [email protected]

NTUA

Elias Tragos

Phone: +30 21 0 7721511 Fax: +30 21 0 7722534 e-mail: [email protected]

AAU

Albena Mihovska

Phone: +45 9635 8639 Fax: +45 98151583 e-mail: [email protected]

AAU

Sofoklis Kyriazakos

Phone: +45 9635 7505 Fax: +45 e-mail: [email protected]

SMC

Lino Moretti

Phone: +39 02 2437 7255 Fax: +39 02 2437 7989 e-mail: [email protected]

TID

Juan Lara

Phone: +34 93 29 56365 Fax: e-mail: [email protected]

Page 3 (80)

WINNER

D1.3 v1.0

Abbreviations 3GPP

Third Generation Partnership Project

ACELP

Algebraic Codebook Excited Linear Predictive

AR

Augmented Reality

BAN

Broadcast Area Network

BER

Bit Error Ratio

CBR

Constant Bit Rate

CIF

Common Intermediate Format

CNG

Comfort Noise Generator

CS

Circuit Switched

DAB

Digital Audio Broadcasting

DVB-T, S, C, H

Digital Video Audio Broadcasting (Terrestrial, Satellite, Cable, Handheld)

FCC

Federal Communications Commission

FTP

File Transfer Protocol

FWA

Fixed Wireless Access

GoP

Group of Pictures

GPS

Global Position Satellite

GPRS

General Packet Radio Service

GUI

Graphical User Interface

HDTV

High Definition Television

HTML

HyperText Markup Language

IP(v6)

Internet Protocol (version 6)

ISM

industrial, scientific, medical

ITU

International Telecommunications Union

LAN

Local Area Network

MMS

Multimedia Message Service

MP3

Mpeg1 layer 3

MPEG

Motion Picture Expert Group

MPMLQ

Multi-Pulse Maximum Likelihood Quantization

PAN

Personal Area Network

PC

Personal Computer

PCM

Pulse Coded Modulation

P-MP

point-to-multipoint

QCIF

Quarter Common Intermediate Format

QoS

Quality of Service

RAN

Radio Access Network

RAT

Radio Access Technology

SERR

Service Requested Bit Rate

SID

Silence Insertion Descriptor

Page 4 (80)

WINNER

D1.3 v1.0

SMS

Short Message Service

SYSA

System Assigned Bit Rate

TCP

Transmission Control Protocol

UDP

User Datagram Protocol

UMTS

Universal Mobile Telecommunications System

URL

Uniform Resource Locator

UWB

Ultra Wideband

VAD

Voice Activity Detection

VBR

Variable Bit Rate

VGA

Video Graphics Array

VNC

Virtual Network Computing

VR

Virtual Reality

WINNER

Wireless World Initiative New Radio

WLAN

Wireless Local Area Network

WP

Work Package

WWI

Wireless World Initiative

WWW

World Wide Web

Page 5 (80)

WINNER

D1.3 v1.0

Table of Contents 1. Introduction ...........................................................................................................10 2. Background & Assumptions.............................................................................10 2.1

Initial Assumptions.................................................................................................................................. 10 2.1.1 General Assumptions about WINNER ....................................................................................... 10 2.1.2 Coverage, service............................................................................................................................ 11 2.1.3 Scenarios .......................................................................................................................................... 11 2.1.4 Location............................................................................................................................................ 11 2.1.5 Hardware .......................................................................................................................................... 11 2.1.6 Economics ........................................................................................................................................ 11

3. Services classes ..................................................................................................12 3.1 3.2 3.3 3.4

Services in the WINNER context .......................................................................................................... 12 Service classes table ................................................................................................................................ 12 Service classes grouping......................................................................................................................... 15 Alternative service classes list............................................................................................................... 16

4. Usage scenarios...................................................................................................17 4.1 4.2

Generic Applications............................................................................................................................... 17 Scenario Elements.................................................................................................................................... 20

5. Analysis of WINNER system concept ............................................................23 5.1

Definition of System Concept................................................................................................................ 24 5.1.1 Generic Aspects .............................................................................................................................. 24 5.1.2 System Mode Aspects .................................................................................................................... 24 5.2 Initial WINNER System Modes............................................................................................................ 25 5.2.1 Deployment Concepts.................................................................................................................... 25 5.2.2 Initial Physical Layer Modes ........................................................................................................ 25 5.3 Review of initial WINNER System Concepts vs. WP1 Scenarios.................................................. 26

6. Business and Economic Analysis ...................................................................28 6.1 6.2

6.3 6.4 6.5 6.6

The Generalised Business Framework ................................................................................................. 28 Domains..................................................................................................................................................... 29 6.2.1 Traditional mobile telecommunications...................................................................................... 29 6.2.2 MVNO mobile telecommunications............................................................................................ 29 6.2.3 Fixed telecommunications............................................................................................................. 29 6.2.4 Fixed Internet................................................................................................................................... 30 6.2.5 WISPs and commercial hotspot operators.................................................................................. 30 6.2.6 "Value add" hotspot operators (e.g. Coffee shop)..................................................................... 30 6.2.7 Free hotspot providers (community and general members of the public)............................. 30 6.2.8 Broadcasting – network operation / content provision............................................................. 30 6.2.9 End user service/content provision (GNU software, freeware, P2P, for money, etc.)........ 30 6.2.10 Content retail (not networked/download)................................................................................... 30 6.2.11 Financial transactions..................................................................................................................... 30 Actors......................................................................................................................................................... 30 Relationships............................................................................................................................................. 31 Examples ................................................................................................................................................... 31 Open issues................................................................................................................................................ 33

7. Traffic models .......................................................................................................33 7.1 7.2 7.3 7.4 7.5

Internet/Browsing..................................................................................................................................... 33 Conversational Voice Model.................................................................................................................. 33 Video Streaming....................................................................................................................................... 33 Streaming of audio ................................................................................................................................... 33 File transfer Model................................................................................................................................... 34 Page 6 (80)

WINNER

D1.3 v1.0

7.5.1 FTP Traffic Model.......................................................................................................................... 34 7.5.2 TCP Overhead ................................................................................................................................. 35 7.5.3 Time estimation for WINNER services ...................................................................................... 36 7.6 Interactive activities ................................................................................................................................. 37 7.6.1 Traffic Model For Internet Gaming............................................................................................. 37 7.6.1.1 Online gaming Quality of Service (QoS) requirement ................................................ 37 7.6.1.2 Game traffic characteristics.............................................................................................. 38 7.6.1.3 Game Traffic Model.......................................................................................................... 38 7.6.1.4 Use of Game Traffic Model ............................................................................................. 39 7.6.1.5 Future Mobile Gaming Applications QoS metrics ....................................................... 40 7.6.2 Telesurgery ...................................................................................................................................... 40 7.6.2.1 Requirements for a wireless System Beyond 3G.......................................................... 40 7.6.2.2 Traffic models ..................................................................................................................... 41 7.6.3 Telepresence.................................................................................................................................... 42 7.6.3.1 Application requirements.................................................................................................. 42 7.6.3.2 Telepresence Traffic models ............................................................................................ 42 7.7 TCP – IP .................................................................................................................................................... 42 7.7.1 TCP/IP Overhead............................................................................................................................ 42

8. Conclusion.............................................................................................................44 9. References.............................................................................................................45 10. Annex – Scenario generation and analysis procedure .............................46 10.1 Scenario generation and analysis procedure........................................................................................ 46 10.1.1 Methodology to identify scenario elements ............................................................................... 46 10.1.2 Scenario analysis procedure and generic application types..................................................... 48 10.2 Further steps in the Methodology and analysis................................................................................... 49 10.2.1 Business and Economic analysis .................................................................................................. 49 10.2.2 Translation of Service requirements into Radio Access System requirements.................... 49

11. Annex - Service Clases Grouping ...................................................................50 11.1.1 11.1.2 11.1.3 11.1.4 11.1.5 11.1.6 11.1.7

One, two, multi-way communication .......................................................................................... 50 Media and data................................................................................................................................ 50 Degree of interactivity ................................................................................................................... 51 Source to destination...................................................................................................................... 51 Symmetry ......................................................................................................................................... 52 Mobility and Range........................................................................................................................ 54 Granularity ....................................................................................................................................... 54

12. Annex - Traffic Models .......................................................................................56 12.1 Internet/Browsing..................................................................................................................................... 56 12.2 Conversational Voice Model.................................................................................................................. 58 12.2.1 Audio Codecs .................................................................................................................................. 58 12.2.2 Example Codec (G.723) ................................................................................................................ 58 12.2.3 Voice Traffic Characteristics ........................................................................................................ 59 12.2.3.1 Single Speaker Model ....................................................................................................... 59 12.2.4 Packet Voice Traffic Model.......................................................................................................... 60 12.3 Video Streaming....................................................................................................................................... 60 12.4 Streaming of audio ................................................................................................................................... 65 12.5 FTP ............................................................................................................................................................. 66 12.6 Telesurgery................................................................................................................................................ 68 12.7 Telepresence.............................................................................................................................................. 70 12.8 Gaming Traffic Characteristics.............................................................................................................. 71

13. Annex – TCP/IP .....................................................................................................72 13.1 13.2 13.3 13.4

TCP/IP Definition .................................................................................................................................... 72 Transport layer: ........................................................................................................................................ 73 TCP ............................................................................................................................................................. 73 IPver4......................................................................................................................................................... 76 Page 7 (80)

WINNER

D1.3 v1.0

13.5 IPver6......................................................................................................................................................... 79 13.6 Mobile IP................................................................................................................................................... 80

Page 8 (80)

WINNER

D1.3 v1.0

List of tables Table 3-1 Service Classes and characteristics ........................................................................................................13 Table 3-2 Service classes mapping into existing systems ....................................................................................15 Table 3-3 Grouping of service classes.....................................................................................................................16 Table 3-4 Reduced list of Service Classes ..............................................................................................................17 Table 4-1 Generic Applications................................................................................................................................18 Table 5-1 Initial Physical Layer Modes (cfr. D7.3) ..............................................................................................25 Table 5-2 Initial WINNER System Modes.............................................................................................................26 Table 5-3 Mapping of initial system modes to test scenarios..............................................................................26 Table 7-1 FTP Traffic Model Parameters ...............................................................................................................34 Table 7-2 .......................................................................................................................................................................37 Table 7-3 Counter Strike traffic characteristics and suggested approximation [7]..........................................39 Table 7-4 Service Classes for Telesurgery application ........................................................................................41 Table 7-5 Traffic Model Comparison......................................................................................................................41 Table 12-1: Choi WWW traffic model parameters ...............................................................................................57 Table 12-2: Parameters for Voice modelling with Exponential Distribution...................................................60 Table 12-4: Frame sizes of different resolutions [kbit] ........................................................................................62

R

Table 12-5: Average bit rate C of the MPEG-1 compressed video sequence “Star Wars” for different resolutions and refresh rates, and with GoP (15,3). ....................................................................................64

R

Table 12-6: Average bit rate C of the MPEG-2 compressed video sequence “Star Wars” for different resolutions and refresh rates, and with GoP (15,3). .....................................................................................64

R

Table 12-7: Average bit rate C of the MPEG-4 compressed video sequence “Star Wars” for different resolutions and refresh rates, and with GoP (15,3). .....................................................................................64

R

Table 12-8: Average bit rate C of the MPEG-1 compressed video sequence “Star Wars” for different resolutions and refresh rates, and with GoP (15,1). ....................................................................................65

R

Table 12-9: Average bit rate C of the MPEG-2 compressed video sequence “Star Wars” for different resolutions and refresh rates, and with GoP (15,1). .....................................................................................65

R

Table 12-10: Average bit rate C of the MPEG-4 compressed video sequence “Star Wars” for different resolutions and refresh rates, and with GoP (15,1). .....................................................................................65

List of figures Figure 3-1 Service Classes and characteristics ......................................................................................................14 Figure 4-1 Generic Applications - Layered Approach .........................................................................................19 Figure 4-2 Generic Applications for WINNER .....................................................................................................19 Figure 7-1 Model for generating FTP traffic ..........................................................................................................35 Figure 7-2 FTP over TCP ..........................................................................................................................................36 Figure 12-1: Structure of a WWW page.................................................................................................................56 Figure 12-2: Sequence and parameters for a WWW session...............................................................................57 Figure 12-3: Choi's Behavioral Model ....................................................................................................................58 Figure 12-4: Output of Speech Coder G.723 - High Rate (6.3 kbit/s)...............................................................59 Figure 12-5: Single Speaker Model .........................................................................................................................59 Figure 12-6 Model for FTP Use...............................................................................................................................66 Figure 12-7: Server-server interaction.....................................................................................................................67 Figure 12-8: France Telecom - Telesurgery ...........................................................................................................69 Figure 12-9 Example of server and typical client traffic of a 1h session....................................................72

Page 9 (80)

WINNER

1.

D1.3 v1.0

Introduction

This document presents the final state for the definition of the usage scenarios developed for the WINNER system. The objectives of WINNER is to develop a single new ubiquitous radio access system concept whose parameters can be scaled or adapted to a comprehensive rage of mobile communication environments from short range to wide area. The ubiquitous radio access system concept will provide terrestrial communications including point to multipoint, but not including the BAN and PAN elements. In previous stages ([1], [2]), the usages scenarios composed of scenarios elements have been identified. These initial scenarios have been developed from the motivations of some key user groups without any reference to the technology. These scenarios had been studied regarding the requirements needed from WINNER. A thorough analysis of these scenario elements has led to the definition of generic applications (group of usage scenarios by applications type) and a list of service classes with their requirements. The usage scenarios, generic applications and service classes have been revised and refined taken into account feedback from other work packages. Furthermore, two new analyses of the usage scenarios have been tackled: a review of the WINNER system concept and a confrontation on user scenarios and requirements developed within WP1; then a first attempt to evaluate the scenarios on a business and economic angle. Another important output of the WP1 work is the definition of new/evolved traffic models applicable for the generic applications and service classes developed. The new traffic models concerning File transfer and interactive activities have been developed and TCP/IP overheads evaluation has been considered.

2.

Background & Assumptions

2.1

Initial Assumptions

This chapter presents initial assumptions used by WP1 for the scenario work. They are very general and relate to several topics: WINNER scope, coverage and service, scenarios, location, hardware and economics.

2.1.1

General Assumptions about WINNER

It is assumed that there will be no significant, unexpected, changes to the global social, political or economic landscape. Nor will there be significant issues against the use of radio frequency emissions. The WINNER project aims at a terrestrial communications system. The first deployment is expected at the earliest in 2010. Large networks will not be deployed before 2015 so WINNER should meet the user needs of 2015 and after. All significant user needs should be met by the WINNER system, but where there are other systems available, which can meet some of these needs, they can work in conjunction with WINNER. The significant user needs for 2015 will be estimated from the current user needs that cannot be met by existing and near future systems. In particular the following assumptions have been made about the WINNER system [1]: • A single new ubiquitous radio access system concept whose parameters can be scalable or adapted to a comprehensive range of mobile communication scenarios from short range to wide area. • The ubiquitous radio access system concept will provide terrestrial communications, but not including BAN and PAN elements. • The ubiquitous radio access system concept will be self-contained, allowing WINNER to target the chosen requirements without the need for inter-working with other systems. • Where other systems are available (including BAN/PAN, as well as, for example, evolved 3G and WLAN), cooperation, inter-working and infrastructure reuse may be used for mutual benefit. The WINNER concept will fit into a multi access structure allowing an Always Best Connected solution. • First deployment expected at the earliest in 2010, widespread from 2015.

Page 10 (80)

WINNER

D1.3 v1.0

•

The WINNER RAN should provide significant benefit to users, manufacturers and/or providers, compared to alternative technologies, such as evolved 3G or WLAN systems. Examples of benefit might include cost, performance, ease of use or ubiquity of service availability. • Requirements will be developed which relate to the expected stakeholder experiences. E.g. from the end user perspective, continuous & ubiquitous link throughput, delay and negotiable quality of service. • Although widely used for publicity purposes, figures such as “peak data rate” have no direct correlation to the stakeholders’ actual experiences; so will not be used as primary targets for the WINNER project. • It is assumed that we will have only one WINNER Radio Access Network (RAN). The WINNER RAN is further based on one WINNER Radio Access Technology (RAT). The WINNER RAT may provide different modes to come up with a flexible solution for different scenarios and propagation conditions.

2.1.2

Coverage, service

The services provided by the WINNER system should be available where they are needed by users. The correlation between geographical location and type of service needed will reduce (e.g. not only “home” services in the home, or “work” services in the office). The WINNER system will need to support a variety of services, with different requirements, and the end to end QoS for these services shall be negotiable and controllable. Some changes are expected concerning the roles of the service, content and network providers. Users may play an active role in some content creation. Each user will use more than one service at a time, including background services that could eventually be used continuously (e.g. Context discovery, interpretation and management, Agents and Push services). It is expected that end-toend services will mostly be built on IPv6.

2.1.3

Scenarios

WINNER will develop a single new ubiquitous radio access system concept whose parameters can be scalable or adapted to a comprehensive range of mobile communication scenarios from short range to wide area. Even if some elements of PAN and BAN systems should be able to interact with WINNER, there will be no system design for these types of scenarios within WINNER.

2.1.4

Location

The WINNER system should provide location information independently from satellite systems such as GPS or Galileo. The quality of this information is assumed to be at least as good as that provided by current GPS for both indoor and outdoor, and hence such requirement is not expected to be highlighted in the WP1 requirements. We should aim at a better quality if it is possible, and should the user scenarios need this, it will be included in the WP1 requirements.

2.1.5

Hardware

Moore's law and estimation of near future disruptive technologies will be used to anticipate the hardware performance in 2010-2015. However precise limitations will not be considered for the WINNER system design. Some assumptions in this domain are useful concerning the scenario work, which is done in WP1 for the whole project. • Battery life will allow at least one day of heavy use without charging • Many different terminal types and capabilities will be available. The terminal capabilities can be adaptable, including in a dynamic manner during an active session. • Terminal form factor and capability may not be closely linked • The density of devices and sensors will be similar to, or higher than, the density of people

2.1.6

Economics

Within WP1, one task deals specifically with the economic evaluation of the usage scenarios. The objective is to check that every scenario has a real business opportunity. The initial assumptions in this field are the following. • Storage and processing will be much cheaper than communication, and readily available on portable devices. • The cost of providing one bit is independent of the service for which it is used, but the value of it depends on the service. • Service capabilities relating to delay, responsiveness and context will be at least as important as those relating to (user) data rate

Page 11 (80)

WINNER

D1.3 v1.0

3.

Services classes

3.1

Services in the WINNER context

Initial service classes were proposed in D1.1 “First Economic and Technical Evaluation per Scenario” [1]. Such classes were defined starting from the consideration of a relatively large number of scenario elements and generic applications. The second step in the new service classes definition was the production of the service context table: scenario elements were grouped by generic applications with the inclusion, when possible, of additional information as QoS requirements (Uplink/Downlink Bit Rate, Delay, Connectivity type, Error rates, Traffic type), Contextual info requirements, Service discovery time, Service Set up time, Mobility, Security, etc. Service classes revision. The service classes revision process have further continued and led to the achievement of the definition of a set of “Final Service Classes”. The successive refining, grouping and discarding process has led to eighteen service classes, summarized in the table shown in chapter 3.2. Such final set of service classes will allow to provide the perspective of the service capabilities required by future radio systems and will permit the derivation of the Winner system requirements. From other work packages of Winner has been asked for a tighter grouping of the existing service classes, which nowadays add up to eighteen, in order to manage easily the technical study of the system. We think that a broad and detailed enough categorization of the service classes is mandatory in order to optimal design the system capabilities. In our opinion it is not a good practice loosing information narrowing the service classes to a few ones. The Winner system has been envisioned flexible enough to cope with a plethora of different services of different kinds, and the rest of layers are to be developed following this principle.

3.2

Service classes table

A synthesis of the service context table was made taking into account four dimensions: data rate, delay, error rate and traffic type. The result of this synthesis was the table of service classes which covers the range of all the identified scenario elements. The four dimensions are: • data rate: from few kbps to 50 Mbps • delay: highly interactive (200ms) • error rate: 10-3 , 10-6 , 10-9 BER • traffic type: SERR (Service Requested Bit Rate), SYSA (System Assigned Bit Rate), Point to Region (see section 5.1.1 in [1]) The following table represents in text format the mentioned synthesis taking into account all dimensions (Data rate, Delay, Error Rate and Traffic Type dimensions) Service Class

Data Rate

1. Real time collaboration and gaming

1-20 Mbps

2. Geographic real time datacast

2-5 Mbps

3. Short control messages and signalling

Delay

Error Rate

Applications

highly interactive (200ms)

1.00E-0.6

15. exchange

Up to 5 Mbps

SYSA

Few Seconds ( >200ms)

1.00E-0.6

5 Mbps

SERR

1.00E-0.6

30 Mbps

SERR

1.00E-0.9

Video streaming (archival)

Up to 50 Mbps

SYSA

Few Seconds ( >200ms) Few Seconds ( >200ms) Few Seconds ( >200ms)

Messaging (data/voice/media) Authentication (m-payment, mwallet, m-ticket, m-key etc.) Web browsing (light weight) Messaging (data/voice/media) (medium weight) Access to corporate database (lightweight) Audio on demand Web browsing (medium weight) Internet radio Access to databases (heavy weight), filesystems, Video download/upload Peer-to-peer file sharing Video streaming (normal)

File

16. Video streaming 17. High quality video streaming 18. Large files exchange

1.00E-0.6 1.00E-0.9

High quality video telephony Collaborative work Standard data call Access to databases, filesystems,

1.00E-0.6

Table 3-1 Service Classes and characteristics

The following plot represents in pictorial format the mentioned synthesis taking into account three dimensions (Data rate, Delay, Error Rate dimensions)

Page 13 (80)

Data Rate (Mbps)

WINNER

D1.3 v1.0

BER BER 10 --33

50 17

12

7

10

18

-6 10 -6 -9 10 -9

1

5 2

5

6

Point to Point

16

11

15

1

Point to Region 0.5

4 3

20

14

10

9

13

8

100

200

Delay (ms)

Figure 3-1 Service Classes and characteristics

In the following is introduced a qualitative mapping of service classes into currently available systems. The WINNER system is expected to coexist with legacy systems (i.e., UMTS, GPRS, WLAN…). This analysis helps to identify to which extent the services corresponding to each service class are currently delivered (the case of service classes highlighted in green in the table), which ones are partially overlapped to other legacy technologies (highlighted in yellow), and which service classes are definitely not covered by existing systems (highlighted in red), thus representing a clear opportunity for the Winner system. Intermediate Service Class 1. Real time collaboration and gaming 2. Geographic real time datacast 3. Short control messages and signalling 4. Simple interactive applications

5. Interactive high multimedia 6. Geographic interactive multimedia broadcast 7. Interactive ultra high multimedia 8. Simple telephony and messaging 9. Data and media telephony

Example applications Telepresence Real time Gaming

Which is the system closest to provide this service class / these applications? Videoconference may be hold at up to 384 Kbps within the UMTS system.

Real time video streaming Collaborative work Alarms Voice control Sensors

UWB applications aim to provide 3-D Virtual Reality for museums. UWB is able to deliver up to 480 Mbps in short range. There are already developed mobile alarm and information systems. It is based on current mobile phone technology (GSM /GPRS /MMS UMTS).

Presence driven transfer Interactive geographical maps Rich data call Robot security

Applications data transfer up to 384 Kbps in UMTS.

Video broadcasting/streaming Localised map download High quality video conference Collaborative work Voice telephony Instant messages Bets and gambling Audio streaming Video telephony (medium quality)

It’s far to even theoretical maximum UMTS data rate or HSDPA rate under realistic network conditions, respectively 384 Kbps and 1 (14 max) Mbps. It’s far to even theoretical maximum UMTS data rate or HSDPA rate under realistic network conditions, respectively 384 Kbps and 1 (14 max) Mbps. Such data rates are only available nowadays on WLAN. UWB will provide more than 50 Mbps in short range, low mobility usage environment. GSM/GPRS mobile. An example of a current gaming system might be the N-Gage from Nokia. UMTS system. UMTS interactive gaming almost reaches these rates/quality.

Page 14 (80)

WINNER

D1.3 v1.0

10. Geographic datacast

Localised datacast/beacons Audio streaming High quality video telephony Standard data call Database, filesystem server

Mobile GIS over UMTS.

Messaging (data /voice /media) Authentication (mpayment, m-wallet, mticket, m-key etc.) Access to corporate database (lightweight) Web browsing Internet radio Access to databases and file systems Video download/upload Peer-to-peer file sharing Video streaming (normal)

GPRS systems have been already developed to enable mobile payment on taxis, for instance.

17. High quality video streaming

Video streaming (archival)

Far even from HSDPA maximum downloads data rate (up to 14 Mbps).

18. Large files exchange

High rate data transfer (upload/download)

Very far from this high data rate (GPRS/UMTS/HSPDA) or this range/mobility (WLAN).

11. Rich data and media telephony 12. LAN access and file service 13. Multimedia messaging

14. Lightweight browsing

15. File exchange

16. Video streaming

Current systems do not cover this high data rate (GPRS/UMTS) or this range/mobility (WLAN). WLAN or UWB-based systems. Only in short range.

WAP or WML protocols (even HTML in future) over UMTS enable browsing.

Any system cannot deliver data rate this high (GPRS/UMTS case) or this range/mobility (WLAN case).

HSDPA allows downloads up to 14 Mbps (1 Mbps on realistic network conditions).

Table 3-2 Service classes mapping into existing systems

As can be seen from table above, the different service classes are covered in a different measure by existing systems, leading to various mismatches among technical requirements for a given service class and existing capabilities. Some service classes demand a too high data rate for systems lacking nowadays of such potential, whereas in other cases the short-delay/high-interactivity requirement is not guaranteed.

3.3

Service classes grouping

In the service classes revision process another analysis step has been identified in the grouping method. Such method consists in the grouping of service classes according to some basic macro-characteristics (See Annexe 10.2). The “fundamental” characteristics identified are: • • • • • • •

One, two, multi-way communication Media and data Degree of interactivity Source to destination Symmetry Mobility and range Granularity

The grouping intends to identify the major trends and it does not exclude potential alternative way of usage of the service classes. In other words, a service class that is placed in one group may in some cases have characteristics of another group. This happens because every service class can be used by different kind of applications that may have different nature as regarding to the specific “fundamental” characteristic considered.

Page 15 (80)

WINNER

3.4

D1.3 v1.0

Alternative service classes list

Demands for a reduction on service classes’ number have come from other work packages. As stated in point 3.2, we think the correct approach is maintaining the whole service classes’ mixture in order to allow a system design the more complete and optimal as possible. The reduction has been demanded in order to ease the mathematical treatment and design of the system, but this is rather difficult to the extent that there are no clear criteria for grouping service classes. Reduction is possible if a criterion is given, a criterion that certainly would come from design choices already met, since a given design always will focus on optimising the system performance on a set of given characteristics; be e.g. either delay, data rate, feasibility of broadcast/multicast or any combination of these. For instance, if design is to be optimised for delay then service classes can be aligned with respect to their delay requirements. In other words, the service classes can be grouped when the design space has already been narrowed. This means that service classes refining is actually an implicit part of the system design process, and thus out of the scope of WP1, which solely deals with the requirements imposed to such a system. Nevertheless, some alternative list can be outlined in terms of the characteristics that in our opinion might be probably more exigent when designing the system; namely delay and data rate. The grouping table of foregoing point has been useful to match service classes, highlighting the main additional characteristics of each one and helping the naming of these alternative service classes.

1 Real time collaboration and gaming 2 Geographic real time datacast 3 Short control messages and signalling 4 Simple interactive applications 5 Interactive high multimedia 6 Geographic interactive multimedia broadcast 7 Interactive ultra high multimedia 8 Simple telephony and messaging 9 Data and media telephony 10 Geographic datacast 11 Rich data and media telephony 12 LAN access and file service 13 Multimedia messaging 14 Lightweight browsing 15 File exchange 16 Video streaming 17 High quality video streaming 18 Large files exchange

Commun ication type a b c x x x x x x x

Interactivity

Data rate

Data QoS size

Mobility

d

g x

i x

m x

e f x x

x x x

x x x x x

x x x x x

x x x x

x

x x x

x x x

x

x x x

x

x x x

x x x x x

x x x x

x

h

j

k x

l

x x x x x x x

x

x x x x x x x

x

x

x x x x x x x x x

o

p

x x x

x x x

x x x x

n

x x x x

x x x x x x

x x

x x x

Where letters stands for the grouping methods most relevant to the system design:

b) c) d) e) f) g) h)

a) One-way communication Two-way communication Multi-way communication Asymmetric interactivity Symmetric interactivity No/Low interactivity Symmetric Data Rate Asymmetric Data Rate

i) j) k) l) m) n) o) p)

Symmetric Data Size Asymmetric Data Size Symmetric QoS Asymmetric QoS Low mobility, short range Low mobility, general range General mobility, short range General mobility and , short range

Table 3-3 Grouping of service classes

This informative reduced list is aimed to help to provide some preliminary results and there is no guarantee that such an approach leads to an optimal design. We strongly disagree with any approach that bases the design exclusively in this (or others) reduced service classes list without keeping in mind the

Page 16 (80)

WINNER

D1.3 v1.0

existing mixture of service classes, each one with its own peculiarities. Maintaining the design space open enough is one of the premises for this first phase of the project. Alternative service class Multi way, highly interactive. Asymmetric, interactive, low rate. Multi way, interactive, high rate. Conversational, soft BER. Conversational, symmetric QoS, tight BER. 1-Way, Asymmetric, few second delay tolerant.

Delay requirement < 20 ms 20 –100 ms

Bit rate margin

BER margin

1 – 20 Mbps 8-512 Kbps

10-6, 10-9 10-6, 10-9

Included original service classes 1,2 3,4

20 –100 ms

1-50 Mbps

10-3, 10-6

5,6,7

100-200 ms 100-200 ms

8-512 Kbps 1-50 Mbps

10-3 10-3, 10-6

8,9,10 11,12

>200 ms

8 kbps - 50 Mbps

10-6, 10-9

13,14,15,16,17,18

Table 3-4 Reduced list of Servi ce Classes We also disagree with assigning the reduced service classes a given priority, since even in the original list case was arguable to do so, much more in the case of this reduced set grouped around delay and achievable bit rate criteria, where each refined service class contains a mixture of service classes, each one with a given a priori priority, if any.

4.

Usage scenarios

Given the diverse range of users and converging markets of relevance to WINNER, an efficient mechanism to create useful scenarios which are both realistic and challenging has been developed. Additional background detail on the methodology is available in WINNER Deliverable D1.1 [1]. This methodology has led to the identification of a large number of scenario elements for certain user groups combined to their fundamental motivations. From the user scenario elements, the usage scenarios have been defined by taking under consideration the technology and economic perspective of each scenario element. Then, they have been grouped by generic application type.

4.1

Generic Applications

From the service context analysis of the scenario elements, it was revealed a great variety of different applications. These applications were covering most of the existing telecommunication applications and some promising future ones. These applications in many cases were appearing similarities in many points. By considering these similarities, a much sorter list of generic applications was developed. Each generic application correlates a group of different applications with common characteristics mainly from the user point of view and not based on pure technical attributes. After the initial generic applications proposed in D1.1 [1], revision proves have further continued and a grouping process has led to nine Generic Applications. The Table 4-1 describes these nine Generic Applications with some description and identification of their main characteristics. Generic Application 1. Voice telephony 2. Video Telephony 3. Video Conference 8. Instant Messaging, Chat, Forum

Main Characteristics Symmetric traffic Medium interactivity

Description

Symmetric traffic Medium interactivity Symmetric traffic Medium interactivity PT-to-MPT

Video telephony of different quality based .on the network and the device capabilities.

Symmetric traffic Medium interactivity

Simple voice data telephony with a wide variety of options as regarding the quality or the techniques.

Multiparty video communication. Messages with very short delivery time for instant discussions, either through text and/or low quality audio and/or video of limited size.

Page 17 (80)

WINNER 23. Tele-presence 4. Voice messages

4 High interactive Application s

5 Secure Connection

6 LAN/WEB Access 7 Streaming Application s 8 Navigation / Guidance 9 Remote Control

Symmetric traffic Medium interactivity Highly asymmetric traffic Low interactivity (pull)

5. Short data messages

Highly asymmetric traffic No interactivity (push)

6. Multimedia Messages

Highly asymmetric traffic Low/no interactivity (pull/ push)

18. Transfer of Files

Highly asymmetric traffic Low interactivity

7. Broadcast and Public Info

One-way traffic PT-to-Region

17. Media Broadcasting

One-way traffic No interactivity (push)

13. Information Sharing

Asymmetric traffic Low interactivity PT-to-MPT

9. Network Games

Symmetric traffic High interactivity

22. Collaborative work

Symmetric traffic High interactivity

10. M-payment

Asymmetric traffic Low interactivity

14. Secure Browsing and Transfer

Asymmetric traffic Low interactivity

19. Intranet Access

Asymmetric traffic Low interactivity

20. Database Access

Asymmetric traffic Low interactivity

2 Messaging

3 Broadcast

D1.3 v1.0

11. LAN Access 12. Internet Style Browsing 16. Streaming Media

Asymmetric traffic Low interactivity Asymmetric traffic Low interactivity Highly asymmetric traffic Low interactivity

15. Advertising

Highly asymmetric traffic No interactivity (push)

21. Navigation and Guidance

Asymmetric traffic Low interactivity

24. Control

Asymmetric traffic Medium interactivity

Virtual transmission of the presence of a physical person to a remote physical or virtual place. Simple voice messages. Small/limited size data messages delivering unformatted text or small size data with no guaranteed delivery time. The messages delivered automatically to the user. Messages that deliver formatted text, pictures, video, audio or any other type of files, up to limited total size. The messages are stored remotely until the user request them (similar to e-mail), or they are delivered automatically to the user. Transfer of any type and size files. In some cases the transmission time can be specified and guaranteed. Transmis sion of data to a region where every adapted device can receive it. TV and radio broadcasting, through the mobile network in a specified area, which could be very wide (e.g. globally) to very narrow (a building or a room). Sharing information with a group of people of common interest or for a common purpose Multiplayer network games, from simple lightweight lottery games, to very heavy 3D fast action games. Interactive and remote communication with exchange of information in real-time and through audio/video/data calls. Apart from persons, the communication may concern machines as well. Financial transactions performed through mobile devices. Accessing of e-commerce Internet style web sites anywhere reliably and securely through a mobile device Access an Intranet through a very secure wireless connection. Access to database, upload and download files, browse and search the database content through secure wireless connection. Access a LAN and all the LAN’s resources. Access Internet style web sites anywhere through a mobile device Streaming of audio, video clips and radio or television programs. Personalized, context aware advertisements. Navigation system which with the use of enhanced geographical maps and context awareness leads the users or vehicles to their destinations and also can propose potential places of interest. Remote control of machines like robots, house equipments, etc. The control can be done by a person through a mobile device or by an other machine connected in the network.

Table 4-1 Generic Applications

Page 18 (80)

WINNER

D1.3 v1.0

A Generic Application consists of a control flow and one or more generic dialogs. This application also can be presented as the middle level in a layered structure. On the top of the layered structure is a more generic, application-oriented service, and at the lower level of this hierarchy is the group of service classes, associated with the generic application, as depicted in Figure 4-1Figure 4-1.

Application-oriented services

Generic Applications

Service Classes

Figure 4-1 Generic Applications - Layered Approach

The generic services are transparent to the users that request services. These are interpreted to the appropriate service classes in the lowest layered, which are close to the system. As an example, a user is willing to send a video message to someone. This is part of the generic application “Messaging” that is mapped to the related service classes. This information is the important information for the network, since the admission control and other system mechanisms will be based on the characteristics of this class. 1. Voice telephony 2. Video telephony 3. Video conference 8. Instant messaging, Chat, Forum 23. Telepresence

7. Broadcast and public info 13. Sharing information 17. Media broadcasting

2. Messaging

Service classes 1, 7, 8, 9, 11

3. Broadcast

9. Network games 22. Collaborative work

11. LAN access 12. Internet style browsing

4. High interactive Applications

6. LAN/WEB Access

Service classes 5, 6 Service classes 8, 13, 14, 15, 18

15. Advertising 16. Streaming media

21. Navigation and guidance

4. Voice messaging 5. Short data messages 6. Multimedia messages 18. Transfer of Files

1. Telephony / Conference / Chat

10. M-payment 14. Secure browsing and transfer 19. Intranet access 20. Database access

5. Secure Connection

Service classes 12, 13, 14, 15, 18 Service classes 1, 2, 7

7. Streaming Application

24. Control

8. Navigation / Guidance

Service classes 5, 10, 14, 16, 17 Service classes 12, 14

9. Remote Control

Service classes 3, 5 Service classes 1, 4, 10

Figure 4-2 Generic Applications for WINNER

Page 19 (80)

WINNER

4.2

D1.3 v1.0

Scenario Elements

The D1.1 [1] presents all the scenario elements identified during the initial process of the WP1 work. In order to reduce the list of the scenario elements the most interesting of them have been selected and they are presented below. From each Generic Application, the most representative, the most technical challenging, the ones that give different flavours of the same application have been selected. Special care was taken in order the selected scenario elements to cover all the range of the technical requirements of the system. The following examples of scenario elements represent different association of user type and motivation for each generic application. The numbers (if any) are referencing to scenarios elements list of the D1.1[1]. Telephony / Conference / Chat This group represents applications from the traditional mobile telephony to enhanced telephony and instant discussions with a wide variety of options as regarding the quality, the data exchanged (text, audio, video) or the techniques (VoIP for example). 20 – (Old / Individuality and Family) An old couple in Berlin communicates through Internet with their daughter who studies in Paris with the use of text, audio and video conferencing software programme. In parallel they are able to exchange files like pictures, song, etc., with the use of the same software programme. 40 – (Youth / Communications) A teenaged girl makes and Internet phone call to her boyfriend who studies in a foreign country and has no Internet access in his room (traditional telephony set). 34 – (Youth / Individuality and Family) James, currently on vacation, detected that both his sister (on the train) and his parents (at home) are accessible for a virtual reality connection so he has set up a multicast VR-call (virtual reality call) through his device to share with them his news and some of the spectacular scenery. His sister accepts the call, keeps on her VR glasses and enjoys the view from the tropical island of Bora Bora. 118b – (Remote Worker / Cooperation) While doing his homework, a 9 year old boy is meant to offer some insights on everyday life in Egypt. In a brief 3-way telephone conference, his father offers to pass over to pass over the query to the D-Me to search for an available direct contact with a child in Egypt. Ten minutes later, the boy is videoconferencing at home with a girl of his own age, and recording this real-time translated conversation as part of his homework. 3 – (Old / Culture) A 65 years old housewife joints an Internet horticulture forum to get some expert opinions and exchange ideas and advices with other hobbyist from all over the world. 39 – (Youth / Communications) A teenager joint chat room where he/she can meet other teenagers from all over the world, discuss about topics of common interest and make privet audio/video conversations with others. Messaging This group represents the transfer of all type of messages (text, pictures, video, audio or any type of files) of any size. They are delivered automatically to the user, and in some case the transmission time can be specified and guaranteed. 32 – (Old / Instruction, Control) Using voice commands Annie adjusts the light levels and commands a bath. 36 – (Youth / Indiv iduality and Family) Jason decides to tell his cousin about the movie he watched last night and tries to send a video message showing him with a new cap he bought from the movie merchandising, but Jason's user profile doesn't allow him to make any data transmissions until his prepaid account has been topped up. Jason's parents

Page 20 (80)

WINNER

D1.3 v1.0

pay for a plain call he is still allowed, and his mother's phone automatically notifies her that his account needs to be topped up. 49 – (Youth / Emotion) A teenaged girl sends an e-card to a friend of her who lives in another city. 153 - (Tourist / Sharing experiences) A tourist connects his digital camera to his hotel Ethernet and sends some photos to his friends mail account. 133 – (Tourist / Augmentation, reality) In the afternoon, Mr and Mrs Bean are taking a tour of a historic castle. As they are strolling from room to room, they can view on their glasses interesting information about various artefacts. For an additional fee (as part of the admission ticket) they can view an augmented reality (AR) demonstration of life in the castle hundreds of years ago as they walk through it. The AR movie can be downloaded in advance or run as a real-time connection. As they walk from room to room, a part of the AR movie is played, showing typical life scenes in that room such as people having dinner in the dining room. Broadcasting This group represents transmission of data (text, information, TV, radio) to an area where every adapted device can receive it. The area could be very wide (e.g. globally) to very narrow (a building or a room). Vehicle to vehicle communications A vehicle informs other vehicles in proximity (around itself) about sudden change in its driving behaviour (e.g. slipping, skidding and heavy braking), which could probably lead into a collision with other vehicles. (when a vehicle brakes hard, the application send a messages to other vehicle following behind). Road-side infrastructure to vehicle communications Traffic signal communication could increase the safety of drivers or the efficiency of traffic flows. E.g. a traffic light could optimize the duration of green lights for the direction of traffic flow, where more heavy traffic is being experienced. Detection of certain traffic flows is possible via messages between traffic sign and the cars approaching it. 5 – (Old / Entertainment) A viewer captures a multi-stream offering called ‘Interactive Winter Olympics,’ where live multiple cameras were placed around the various sporting venues. Here the stored package remains true to timing of the original live event as the viewer switches between the various locations and sporting competitions. 159 (Tourist / Time, Location, Context) The handset automatically pushes the weather service onto the handset, telling that the weather isn't going to be so good. 97 – (Business / Presence, Availability Signalling) The logistic manager receives an alert from the companies' information system that the level a critical material has reached the lower threshold. High interactive applications Multiplayer network games and interactive/remote communication with exchange of information in realtime and through audio/video/data calls. 10 – (Old / Entertainment) 60 years old, John joints an online casino to play blackjack while his wife is out for shopping 55 – (Youth / Entertainment) A teenager connects his game console with Internet trough his home broadband Internet connection and plays online multiplayer network games with other players from all over the world while with a headset is also able to talk to other players 41 – (Youth / Communications) A Japanese school is holding an outdoor class on "insects" jointly with its Chinese counterpart. The students in the two schools are exchanging information using a wrist watch-type mobile terminal with a built-in camera and an automatic translation function. Children can receive related information (encyclopaedia). Page 21 (80)

WINNER

D1.3 v1.0

119 – (Remote worker / Cooperation) Members of a consortiums cooperating on the development of a computer network system, work remotely on the same testbed located in one of the partners of the consortium. Secure connection Secure wireless connection for financial transaction, access to Intranet or Database. 68 – (Business / Authentication) Sophisticated personal authentication technology allows users to securely purchase expensive items and settle the account through a mobile network. Data downloaded onto mobile terminals can be used to as an entry pass in lieu of a physical ticket. 139 – (Tourist / Commerce) Carmen goes downstairs onto the street, as her driver arrives. When Carmen gets into the car, the VAN system (Vehicle Area Network) registers her and by doing that she sanctions the payment systems to start counting. A micro-payment system will automatically transfer the amount into the e-purse of the driver when she gets out of the car 65 – (Youth / Fashion/Trend/Keeping Up) Jenny enjoys very much to make offers to online auctions of very expensive clothes and accessories 115 – (Remote worker / authentication & security) A remote worker uses a very secure encryptions program while transferring very sensitive data to the information system of the company he works to 84 – (Business / Competition) A business provides personalised services and products to its customers through the Internet. 88 – (Business / Freedom, mobility) Ms Bond is on the train, on her way to spend a long weekend with her parents. Although she likes to relax during train rides, she promised to finish some action points at work before the weekend. So, using her M-me (Mobile -me) device she is remotely logged in the corporate network polishing up some reports. An M-me device is very rich in functionalities and provides full mobility and "always on" connectivity to the Internet. LAN/WEB access Access to a LAN or Internet. 128 – (Remote worker / Reference, Data) Users are able to access corporate networks from outside, for example, to instantly retrieve design drawings from a construction site, or receive necessary business data to make presentations at the client's office 135 – (Tourist / Augmentation, reality) When she arrives at the bottom of the Eiffel tour, Annie receives a notice that several cameras are available. They are located in different inaccessible places and she takes control of one of them to take a personalised picture and download it onto her mobile device 13 – (Old / healthcare) A 65 years old lady retrieves healthcare information from a specialized portal Streaming applications Streaming of audio, video clip, radio, television programs, advertising. 7 – (Old / Entertainment) By simply holding up the mobile handset toward the posters at the station or a mail-order magazine, users can obtain information pertaining to the product, place an order and settle the account on the spot 52 – (Youth / Entertainment) As he passes outside a liquor store, his VED alerts him that one of his favourite wines is on sale. He decided to make a quick stop and purchase a bottle to share with his brother over dinner later this

Page 22 (80)

WINNER

D1.3 v1.0

evening. He pays with his e-wallet, one of the main functionalities of the VED and carries on to the concert 9 – (Old / Entertainment) An elderly English man listen Internet the radio station of his hometown while he is his son’s house who lives somewhere in Italy. 35 – (Youth / Individuality and Family) While the only TV set in a family house is reserved by the grandmother to watch her favourite soap opera, the young son of the family is using his PC to watch live his favourite TV show from the TV station web site. Navigation / Guidance Navigation systems with the use of enhanced geographical maps and context awareness leads the users or vehicles to their destinations and also can propose potential places of interest. 94 – (Business / Navigation) A new guidance system is now present: it makes travelers (e.g. Businessman) able to know the best road for a destination anyway and everywhere, at any hour, asking for this to a central database. This system is very used by business managers who travel much in unknown places, and it also permits them to have news, images and video about the city, available hotels and parking, closed central areas (permanent and temporary) realised to contain pollution level, pedestrian areas… These informations are personalised on the basis of their activities, hobbies, desires … It’s possible to book for hotel, parking, restaurant, tickets (travel, theatres, cinemas, etc,) 134 – (Tourist / Augmentation, reality) In the middle of a trek, they are lost. Their paper map is not precise enough (or not up to date) to help them. Hopefully one of them has the virtual reality glasses from his company with him. He uses them to get an updated and precise 3D map of their location with the possible ways out. 149 ( Tourist / Navigation) Mr Smith is on a day out with the family in London, but Mr Smith is not really a regular visitor, so he doesn't know his way around. Therefore he relies on the system to guide him: a remote database contains the graphical representation of the streets, buildings, and the physical characteristics of the metropolis. Blocks of data are transmitted to a vehicle at 60km/h circulating in urban areas, where the on-board application allows the subscriber to visualise the environment ahead. Remote control Remote control of machines as robots, house equipments, etc. 31 – (Old / Instruction, control) Mobile services are used to use mobile handsets to control robots at home 160 – (Healthcare / Instruction/Control) Robotic security & Fire guards, robots for almost any job on home or hospital, self monitoring infrastructure using smart materials and sensors. 168 – Healthcare / Alert, warning & assistance) A persistent high-pressure belt above the city for the last ten days has given fine weather but rising atmospheric pollutants. It is rush hour and the traffic density has caused pollution levels to rise above a control threshold. The city-wide engine control systems automatically lower the maximum speeds (for all motorised vehicles) and when the car enters a specific urban ring toll will be deducted via the Automatic Debiting System (ADS).

5.

Analysis of WINNER system concept

The goal of the WINNER project is to define a single new ubiquitous radio access system concept. The research activity of the project is still in progress. Nevertheless preliminary WINNER System Concept definitions and conclusions have been derived by Wp7 “System Engineering” in the deliverable 7.3 “Initia l System Concept Description”. As clearly stated in such the mentioned deliverable, the WINNER System Concept Description proposed is preliminary and still substantial modifications are possible Page 23 (80)

WINNER

D1.3 v1.0

depending on the progress of the research activity. The final Winner System Concept Description is expected to be presented in the deliverable D7.6 “WINNER System Concept Description”, due at the end of September 2005. The Winner project is addressing a wide range of Layer 1, 2 and 3 technology concepts. Due to the current focus of the work on novel concepts definition rather than on detailed design the different concepts investigated up to now in Winner have reached different level of completeness. Therefore not all elements identified up to now have been included in the initial system concept description but only those that are most relevant to the system concept and necessary to meet the objectives outlined above.

5.1

Definition of System Concept

The system concept is an overall description of the WINNER system made up of basic system building functions and blocks. The system concept has been defined as resulting from a combination of : • generic aspects • system modes. A system mode is a combination of parameters and algorithms that make sense for a particular situation be that radio environment, usage scenario, economic model etc. The elements identified that can form the system modes (and physical layer modes) and the initial (based on the current conclusions of the technical work) system modes to describe the concept and provide a basis for initial evaluation are reported. It must be emphasized that these are not: the only possible modes, the final choice of modes and the only possible/necessary parameters used to define modes. There should not be a one-to-one mapping between system modes and the high-level test scenarios. System modes should be evaluated across a range of test scenarios to understand their performance under different conditions. It should also be noted that the test scenarios do not necessarily capture all circumstances in each the WINNER system may operate and in particular do not describe combinations of, or transitions between, the test scenarios.

5.1.1

Generic Aspects

Generic aspect are defined those aspects that apply in all cases and represent a common characteristic for all system modes and in turn of the Winner system concept. The following aspects have been identified as a generic to the whole system: • • • •

Multi-mode Protocol Architecture Reference Model The set of logical nodes (not yet defined/described) Security and trust aspects Logical and transport channels

Additional items initially developed as part of the System Modes can be moved to Generic Aspects as soon a generalization will be possible. Potential other generic aspects are (or part of).: • • • •

5.1.2

Control and user plane functionalities L2/L3 procedures CRRM Inter-system handover

System Mode Aspects

The following table lists the parameters and algorithms that may be combined to form the system modes. • • • • • • •

CRRM Inter System Handover Co-existence strategies Flexible Spectrum Usage technologies Interference Management Techniques Network Topologies Deployment Concepts Page 24 (80)

WINNER •

D1.3 v1.0

Physical Layer Concepts (Spectrum, Multiple Access, Resource Partitioning, Modulation, Duplexing, Coding)

The Physical Layer related aspects will contribute to the definition of the Physical Layer Mode (PLM). Some of the parameter listed above may result later to be rather generic and could be removed from the list of the System Mode Aspects and added rather to the Generic Aspect list. At the present time, it is deemed that at least the Deployment Concepts and the Physical Layer Concepts will be required to form a system mo de.

5.2

Initial WINNER System Modes.

At the current stage of the project the only parameters that have achieved a sufficient degree of definition to allow preliminary conclusions as for the definition of an initial set of system modes are the Deployment Concepts and the physical layer parameters; from the latter it has been possible to define preliminary Physical Layer Modes (PLM).

5.2.1

Deployment Concepts

The Deployment Concepts identified up to now are: • • • • • •

5.2.2

Single -hop (SB) Fixed Homogenous Multi-hop (FHoMR) Mobile/Moveable Homogeneous Multi-hop (MHoMH) Fixed Heterogeneous Multi-hop (FHeMH) Co-operative Multi-hop (CMH) Peer-to-peer (P2P)

Initial Physical Layer Modes

The Physical Layer Modes identified up to now are represented by the three columns in the following table. They are: FDD-Dedicated (FDD-D), TDD-Dedicated (TDD-D) and TDD-Shared (TDD-S). FDD-Dedicated

TDD-Dedicated

TDD-Shared

(FDD-D)

(TDD-D)

(TDD-S)

Spectrum Freq

0.175 - 6GHZ

0.175 - 6GHZ

0.175 - 6GHZ

Spectrum BW (Min,Max) MHz

2.5 to 50

2.5 to l00

1.25 to 100

Spectrum Type

Dedicated

Dedicated

Shared

Multiple Access

(F+T+S)DMA

(F+T+S)DMA

(F+T+S)DMA

Modulation

DL: OFDM

DL: OFDM

DL: OFDM

UL: GMC

UL: OFDM

UL: OFDM

Modulation Scheme

BPSK, QPSK, l6QAM, 64 QAM

BPSK, QPSK, l6QAM, 64 QAM,256QAM

BPSK, QPSK, l6QAM, 64 QAM,256QAM

Duplex

Half duplex FDD

TDD

TDD

Coding

CC/PCCC/LDPC

CC/PCCC/LDPC

CC/PCCC/LDPC

Multi-antenna technology

LDC + MU MIMO BF

LDC + MU MIMO BF

LDC + MU MIMO BF

Table 5-1 Initial Physical Layer Modes (cfr. D7.3)

It is possible to combine these PLMs with the Deployment Concepts to form some initial System Modes. These system modes have been defined in order to provide a WINNER system that is applicable to a range of situations: •

Able to operate across a range of radio propagations scenarios Page 25 (80)

WINNER • • •

D1.3 v1.0

Support a range of traffic densities Take advantage of different spectrum options Support different deployments - from cellular infrastructure to low-cost minimal deployments

Initial System Mode

Deployment Concept(s)

Physical Layer Mode(s)

1

SH

FDD-D

2

SH

TDD-D

3

FHoMH (CMH)

FDD-D

4

FHoMH (CMH)

TDD-D

5

FHeMH

FDD-D + (TDD-D or TDD-S)

6

MHoMH

TDD-D

7

SH, P2P

TDD-S

8

SH

TDD-S

9

FHoMH (CMH)

TDD-S

Table 5-2 Initial WINNER System Modes

From Table 5-2 it can be seen that system modes 1 and 2 are sub-sets of modes 3 and 4 respectively. These initial system modes should be evaluated in a range of test scenarios in order to assess their applicability and performance. Therefore Table 5-3 shows the test scenarios which the system modes should be investigated (marked by an X). It is planned to start the applicability and performance analysis in the current Phase I on some high priority test scenarios and to complete such analyses in Phase II. Mode

A1

1 2

X

3

B1

C2

D1

B1/B5

C2/C5

D2

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

4

X

X

X

5

X

X

X

X

X

6

X

X

X

X

X

X

7

X

X

X

8

X

X

X

X

9

X

X

X

X

X

X

X

Table 5-3 Mapping of initial system modes to test scenarios

5.3

Review of initial WINNER System Concepts vs. WP1 Scenarios

As stated in D7.3 the definition of the Winner System Concept is in progress. At this stage a preliminary perception of the Winner System Concept results from the combination of Generic Aspects and System Modes. We think that, given the preliminary status of the Winner System Concepts definition process, the foreseen analysis of the Winner System Concepts mapping and confrontation on user scenarios and requirements deriving from WP1 can only be started at this stage without the possibility to achieve conclusive results. We think that at this stage a reasonable approach is to comment the first review of the Winner System Concepts provided in D7.3 vs. initial requirement adding a perspective given from the background developed in WP1. We will use in this initial stage of the discussion the analysis framework provided by D7.3 in chapter 12.3.1 carrying out discussion per logical groups of requirements. Not all the logical groups identified in D7.3 will be considered here but only those that appear relevant for WP1 analysis. Page 26 (80)

WINNER

D1.3 v1.0

Enhanced capabilities •

D7.3: “Until simulations are undertaken it cannot be assessed if the requirements on data rates, delay or spectral efficiency can be met by the proposed concept”.

Some defined generic applications demand strong requirements (very high data rate, short delay and high interactivity) so they are not covered by existing systems. It is crucial that WINNER system concept has the potential to support such scenarios. After conclusion of first simulation it will be possible to draw first conclusions on coherence of Winner system mode performances vs. WP1 scenarios/applications requirements. •

D7.3: “The flexibility of the chosen physical layer building blocks (e.g. (F+T)DMA) should allow the single service and overall traffic symmetry requirements to be achieved”.

The flexibility of the access schemes appears to guarantee the support of all user scenarios defined within WP1 that include applications ranging from symmetrical to highly asymmetrical traffic. •

D7.3: “The necessity of providing mechanisms for broadcast and multicast has been noted but no proposals currently exist”.

The necessity of support of Broadcast/Multicast applications emerges also from WP1 scenarios. Some generic applications (above all the generic application 3 "Broadcast", see section 4.1) require this capability. It is crucial that WINNER system concept has the capability to support such scenarios. •

D7.3: “System modes have been defined for P2P/ad-hoc networking”.

Some interesting scenarios for Ad-Hoc networking have been identified too and it would desirable the support of the Ad-Hoc mode. Services •

D7.3: “All work in the project assumes the support of IP”.

This approach is compatible with user scenarios defined within WP1 although it should be pointed out that QoS requirements in the service classes defined by WP1 can be very demanding. This in turn implies that a fully IP based system should implement IP based QoS control mechanisms capable of compliance with the mentioned WP1 service classes. •

D7.3: “At present there are no stumbling blocks to the support of seamless application access and negotiable end-to-end QoS but the necessary procedures and functions have yet to be detailed”.

These procedures and functions are important for some scenarios and should be defined in the WINNER system concept. QoS features and QoS control mechanisms in particular emerge as a key point for future scenarios/applications. Spectrum and Co-existence •

D7.3: “The Physical Layer Modes allow operation in any appropriate band as identified in the requirements”.

The WINNER coverage, ubiquity an data rate requirements are very demanding. This in turn impact on frequency bands and namely on frequency carriers, frequency bandwidth and pairing status. Coverage and ubiquity requirements of the WINNER scenarios may require both NLOS and LOS operations; typically, in the valuable and crowded NLOS part of the spectrum, it may result more difficult to assure the WINNER scenarios data rates requirements; such requirements will have to be validated versus the envisaged spectrum allocations and the envisaged spectral efficiency to verify the coherence of the WINNER system concept versus the WINNER scenarios.

Page 27 (80)

WINNER •

D1.3 v1.0

D7.3: “Simulations will be required to determine the necessary system bandwidth to meet the other requirements”.

Impact on user data rate needs to be evaluated since, clearly, available system bandwidth together with techniques maximizing spectral efficiency are key factors for assuring enhanced user data rate requirements.

At this stage the definition of the WINNER system concept is in progres s and it has not been finalized yet. Plenty of options are still possible although some major guidelines have been identified. The guidelines and generic characteristic of the WINNER system concept highlighted up to now do not preclude, at this stage, any of the WINNER WP1 Scenarios and Generic Applications. The process of review of WINNER system concept versus WP1 scenarios and applications will be more effectively dealt with in the second part of the current year when work and choices in other WPs will get more mature. Such WINNER system concept review analysis and the identification of possible precluded scenarios will be one of the main objectives of the remaining WP1 activities.

6.

Business and Economic Analysis

In this section we present a framework for the business and economic analysis of potential services and scenarios for WINNER. The aim of this framework is to allow additional prioritisation of services and scenarios, according to their viability in the real world, which can be further used to reduce or prioritise the requirements placed on the WINNER system concept. It is not the role of WINNER to impose, or constrain itself to, a single business structure. Nor is it intended to develop business models, or “operations handbooks” on behalf of any particular actors. Rather, the approach taken is to identify the multitude of current business structures (domains) which may support some or all of the types of services being considered, the key actors within those domains, the roles played by those actors, and the types of relationships needed between those actors. By developing a single generalised framework, we can easily map the actors and relationship required to provide any particular service, within a particular domain. By considering the details of the relationships (e.g. how much Actor X is willing to pay to Actor Y for a particular relationship, and how much Actor Y needs to be paid in order to provide the relationship) it is possible to look whether there is a realistic possibility to provide the service. The common framework also allows for easy comparisons of the same service being provided within different domains, and the flexibility to consider other domains, which have not yet been identified for study. The basic framework is presented below, followed by explanations of the different domains and components of the framework. Finally some examples are presented to clarify the use of the framework. This approach and model have been inspired by, and based on, work previously carried out within the MobileVCE [31]

6.1

The Generalised Business Framework

Page 28 (80)

WINNER

D1.3 v1.0

Content Owner

Service Creator

Content Provider

Service Provider

Content and Service Aggregator

Third party Security/ Authentication house

Advertis

Financial Enablers

User profiling / context analysis

USER

Network Provider

Network Owner

Equipment Supplier

6.2

Domains

A domain may be characterised as being a combination of actors and their relationships which enable the provision of an instance of a service to a user, or which enable a user to provide an instance of a service. Generally this implies a commercial business structure, although not for profit domains also exist, and there may be not for profit actors in some domains. Even in these cases, actors and relationships exist, although the nature of the relationships (or the requirements on the relationships) may vary. The following list of domains identifies those which are clearly relevant for study of WINNER services and scenarios. For each studied service/scenario, a domain specific instance of the business framework should be developed for each of these domains. Other domains may exist, or may develop in the future, and can also be modelled in this way.

6.2.1

Traditional mobile telecommunications

This domain represents the well established mobile telecommunications model where a single network provider acts as the fundamental connectivity provider, physical network operator and service provider for a user. Increasingly it also is becoming possible to access independent service providers within this model, and roaming agreements exist between the main network provider and other network providers.

6.2.2

MVNO mobile telecommunications

In the case of the Mobile Virtual Network Operator, the network provider as seen by the user appears the same as in the traditional mobile telecommunications domain. However, in actuality, the network provider here is not the operator of the physical network.

6.2.3

Fixed telecommunications

This domain represents the provision of telecommunications to fixed locations (home, office, phone box etc.), typically by cable (electrical or optical), although wireless local loop and satellite connections also play a role here.

Page 29 (80)

WINNER

6.2.4

D1.3 v1.0

Fixed Internet

This domain represents the provision of Internet connection to fixed locations by predominantly cabled means.

6.2.5

WISPs and commercial hotspot operators

This domain represents commercial wireless Internet providers, where the user is expected to pay for the connectivity.

6.2.6

"Value add" hotspot operators (e.g. Coffee shop)

In this domain, wireless Internet connectivity is provided to users as an enhancement to some other service, or as a market differentiator.

6.2.7

Free hotspot providers (community and general members of the public)

In this domain, wireless Internet connectivity is provided free of charge, perhaps for the benefit of a community or society, or in order to uphold particular ideals on access to technology and information.

6.2.8

Broadcasting – network operation / content provision

This domain represents the provision of content through a broadcast medium, whether terrestrial, satellite or cable. This may include on-demand services, which may also be emulated by the use of end-user timeshifting via PVRs (personal video recorders), from simple VHS machines through to Tivo devices.

6.2.9

End user service/content provision (GNU software, freeware, P2P, for money, etc.)

Increasingly we are seeing end user generated content and/or provided services proliferating on the Internet, and starting to develop on mobile networks (e.g. Moblogging). Often these are provided for free, or on a trust based payment model. Some of these mechanisms are often used for illegitimate purposes, but also have legitimate application – which should be studied within WINNER.

6.2.10 Content retail (not networke d/download) Content is still frequently provided via physical carriers, purchased through retail outlets, or mail order. Examples include: · CD and DVD music/film industries · Magazine publishing · Gaming / software

6.2.11 Financial transactions Whilst financial enablers are normally considered an integral part of every commercial domain and activity, there are also third party financial enablers (notably “escrow” services, such as Paypal) which may be considered also as separate domains.

6.3

Actors

It would be possible to identify hundreds of different actors who have some involvement in the different domains (particularly considering hardware, which consists of multiple components which can be traced back to raw materials, via a chain of manufactures, sales organis ations, logistics companies etc.). Such detailed analysis would not be useful – the variabilities in estimations would be bigger than the role of many actors, and the resource needed to develop the complete framework would be excessive. In the following list we have identified the most important actors, from the perspective of the business framework. Depending on the particular service and domain being considered, some of these actors will not be relevant in all cases, and at other times there may be multiple instances of a single type of actor. • Content owner • Content provider • Service provider • Service creator • Network / connectivity provider • Network owner (site owners, infrastructure owners) • Equipment suppliers • End users (including machines) • Content and Service aggregators • Advertisers • Financial enablers / institutions • Third party security / authentication house Page 30 (80)

WINNER •

6.4

D1.3 v1.0

User context analyser and profile manager/owner

Relationships

Within the framework, it is necessary to identify, and analyse, the relationships between different actors. For the purpose of business and economic analysis, the main type of relationship which must be considered is that of money flow – between which actors does money flow? in which direction(s)? and how much? Other types of relationships can also exist, and may be interesting or beneficial to study. For example: • Information flows (other than content and direct application data – e.g. context information) • Trust • Contractual (similar to money flows, but not necessarily the same. e.g. with some freeware there is no obligation or contract to provide any payment in return for a service, but is it possible to do so should you wish to show your appreciation for what has been provided) • Legal (company) ownership • User / profile “ownership”

6.5

Examples

In this section we present examples of the business framework, adapted to particular domains.

Content Owner

Service Creator

Service Provider

Content Provider

Third party Security/ Authentication house

Mobile Telco Business Model

Financial Enablers

USER

Network Provider

Network Owner Equipment Supplier

Page 31 (80)

WINNER

D1.3 v1.0

Content Owner

Content Provider

Broadcast Business Model

Advertise

USER

Network Provider

Network Owner

Equipment Supplier

Content

Service Content

Service

Content and Service Aggregato

Third party Securit/ Authenticatio hous

Advertise rs

Fixed Internet Business Model

Financial Enabler

User profiling / context analysis

USE

Network Network Equipment Supplie

Page 32 (80)

WINNER

6.6

D1.3 v1.0

Open issues

This section has presented the tools and methodology needed to carry out practical and useful, analyses of WINNER services and scenarios. The main open issue going forward is what should be analysed – it would not be realistic to carry out analysis of every scenario element identified within the scenarios process, but conversely the set of generic applications may be too general to draw conclusions from analysis. One method may be to use analysis of a small number of representative examples of generic applications to identify if there are particular characteristics of generic applications which create value more readily than others. This could be supplemented by analysis of particular services/applications which have particularly interesting, or unknown, properties.

7.

Traffic models

The definition of reliable and precise stochastical statistical traffic models is a complex and time consuming task requiring an accurate estimate and verification, via real traffic measurements, of statistical parameters resulting from the user behaviour and from specific data traffic characteristics. Such a goal is even more difficult to achieve when the objective is not the characterization of real data traffic types but rather an estimate of traffic models applicable to future user behaviours and data traffic characteristics as is the case when the target context is the Wireless World. The development of basic ideas on the data traffic types and models to be used in the development of new wireless technologies is essential in order to set reference models for an initial benchmarking of new technologies and concepts for wireless communications. These models have two purposes within the WINNER project. In the longer term they will enable system concept performance estimation, against scenarios and project requirements. Within a shorter timeframe they should also be appropriate for use within the technical workpackages for comparative simulations of alternative technology component options. The approach followed in this project has been the initial identification, from the literature or outcome produced by other R&D projects, of “evolved traffic models” suitable for consideration in the context of the Wireless World. A suitable source for these “evolved traffic models” is the Deliverable 2.1 “4G Scenarios and Systems Requirements” of the IST project STRIKE [3]: the traffic models proposed in this context have been adopted as a starting point for WINNER. However, since the scenarios considered within WINNER are not the same as those considered within STRIKE, the parameters of these models have been adapted to be appropriate for the WINNER scenarios. Further to these “evolved traffic models” it is necessary to develop some completely new traffic models within WINNER, to encompass new service types for which reference models are not currently available.

7.1

Internet/Browsing

Based on literature [3], Internet traffic model have been evolved [1] to take account of WINNER constraint. Details of this traffic model is in annex 12.1

7.2

Conversational Voice Model

Based on literature [29], conversational voice model have been evolved [1] to take account of WINNER constraint. Details of this traffic model is in annex 12.2

7.3

Video Streaming

Based on literature [29], Internet traffic model have been evolved [1] to take account of WINNER constraint. Details of this traffic model is in annex 12.3

7.4

Streaming of audio

Based on literature [32], Internet traffic model have been evolved [1] to take account of WINNER constraint. Details of this traffic model is in annex 12.4

Page 33 (80)

WINNER

7.5

D1.3 v1.0

File transfer Model

As FTP is one of the major protocols used for file transfer, its traffic model is presented, as well as the associated TCP overhead. In addition a description of FTP is annexed (see 12.5). Having described FTP, another important aspect for WINNER is the service time estimation. For that purpose all major services are listed and the minimum/maximum or average time is provided. Time estimation is provided from the user point of view, not considering the RAT that could be utilized. This is strongly linked with the user satisfaction, the business models and can result in useful information for system requirements.

7.5.1

FTP Traffic Model

C802.20-03.43 [4] has a detailed description of an FTP model which is based on [5]. The basic model is included here for illustration. See also [6] In FTP applications, a session consists of a sequence of file transfers, separated by reading times. The two main parameters of an FTP session are:

S : the size of a file to be transferred D pc : reading time, i.e., the time interval

between end of download of the previous file and the user

request for the next file. The underlying transport protocol for FTP is TCP. The parameters for the FTP application session are described in Table 7-1. Component

Distribution

Parameters

File size (S)

Truncated Lognormal

Mean = 2Mbytes Std. Dev. = 0.722 Mbytes Maximum = 5 Mbytes

Reading (Dpc)

time

Exponential

Mean = 180 sec.

PDF

fx =

 − (ln x − µ )2  1 exp  , x ≥ 0 2π σx   2σ 2

σ = 0. 35, µ = 14. 45

f x = λe

−λ x

,x ≥ 0

λ = 0. 006 Table 7-1 FTP Traffic Model Parameters

Based on the results on packet size distribution 76% of the files are transferred using an MTU of 1500 bytes and 24% of the files are transferred using an MTU of 576 bytes. For each file transfer a new TCP connection is used whose initial congestion window size is 1 segment (i.e. MTU). The packet arrival process at the base station is described by the TCP model described earlier. The process for generation of FTP traffic is described in Figure 7-1.

Page 34 (80)

WINNER

D1.3 v1.0

Create a file using the file size statistics

MTU ?

MTU = 1500 bytes

MTU = 576 bytes

Complete transfer of the file using a new TCP connection with initial window size W=1

Wait Dpc

Figure 7-1 Model for generating FTP traffic

The importance of the FTP service in a wireless environment is expected to be less than in the wire-line internet. Thus, for the model of a GPRS user it may be negligible. However, due to reasons of completeness an FTP model is recommended as well. Like in the reference model of UMTS the FTP service can be included by describing an FTP file transfer like a web session with only one web request. The arrival process of FTP sessions is chosen as Poisson with a rate of 6· 10-6 session per seconds. The structure of the WAP model is similar to that of the HTTP model except that the web request size will be different. In WAP, a web page will only comprise inline objects if the capability of the handset is appropriate. The type of the handset therefore influences the distribution of the number of inline objects. Of course, if the mobile can not handle images there will be no inline objects, and else their distribution is equivalent to the HTTP case. The document size will be smaller due to the tag compression. The shrinking factor will be around 40%. The distribution of the size of inline objects depends on the resolution which is possible in the handset. Thus, like in the HTTP model the size is lognormal distributed. For each user a fixed shrinking factor dependent on the handset resolution has to be introduced to adopt the distribution appropriately. [6]

7.5.2

TCP Overhead

FTP currently operates on top of TCP’s reliable, byte stream service. An FTP session consists of one control connection, and one or more data connections. The control connection is used for the exchange of commands and replies in simple ASCII format. Each command and reply typically consists of 20-40 bytes. The exchange of commands and replies over the control connection is periodic in nature triggered by user requests. A unique data connection is established for each file transfer or directory listing transfer, and is terminated after the transfer. The closing of the data connection indicates the End of File (EOF). Thus the number of data connections in an FTP session is equivalent to the number of transfers performed. Each data connection follows one of the two modes, active or passive depending on whether the server or client initiates the connection, respectively. In the active mode, the client sends a PORT command to the server indicating the IP address and the port number to which the server should establish the data connection. FTP provides the retrieval of multiple files based on an expression given by the user, for example, using “mget * ”. The files are transferred independently and no form of connection information is shared between each file’s transfer. Each transfer requires the client to send PORT, SIZE and RETR (or equivalent) control commands. The total number of data connections consumed for a multiple file transfer request is (n+1): one to transfer of the name list of files, and n for n file transfers. Figure 7-2 shows a Page 35 (80)

WINNER

D1.3 v1.0

timeline for multiple file retrieval, from the server to the client. The timeline shows the commands and replies exchanged, and the TCP connection establishment-teardown for the data transfer. The dotted box is repeated sequentially for each file transferred. [8]

Figure 7-2 FTP over TCP

7.5.3

Time estimation for WINNER services

In general it is quite difficult to estimate the time required to download a file using FTP. There are several parameters that influence the performance and only simulative and qualitative studies can be made. It is important to know the amount of data to be transferred and the bandwidth available in each mode. Knowing the available bandwidth one can approximate the download time, using simulators that consider several delay aspects. In the case of wireless communications this is more difficult, since additional parameters influence the overall performance. Transfer speeds are in most cases slower due to latency, physical signalling overhead, layer 4 transport and transmission protocol overhead, i.e. TCP overhead, error checking, or protocol headers. In addition, one should also count handshaking negotiation procedures like "slow start" and others. In the following table however, the emphasis was not given on the radio technology or the protocol characteristics, but on the user needs and perspectives. Therefore, the times (min/max/mean), indicate the acceptable time to have a service, so that the user can ‘buy’ the service.

Page 36 (80)

WINNER Application Voice message Simple SMS Advanced SMS Email Email with attachment Multimedia Uncompressed song Individual song (compressed) Album (compressed) 30 min. radio program Photograph Video Mpeg4 movie Mpeg2 (DVD) movie TV program HDTV Short clip message Short clip (high quality) Long clip 3D video clip Drawing Document Ebooks Presentation Software package Small Large Web page Advertising Map Augmented map 3D map VR map Tourist guide

D1.3 v1.0 Size (byte)

Min-time (sec)

Max-time (sec)

Mean-time (sec)

0.5-2.5M 5K 100K 10K 1-10M

1 5

5 60

1 1 1 -

50M 3-5M

10

15

60 -

50M 30M 0.1-5M

2

20

60 60 -

1G 5G 2G/hour 10G/hour 10M 150M 500 M 300M 0.5-5M 0.1-50M 1M-1G 1-50M

5 1 10 5

30 60 600 90

300 600 300 600 60 60 300 300 -

10K 1G 150K 0.1-10M 0.1-1G 1-5G 1-5G 2-10G 1-5M

1 60 60 60 120 60

20 600 300 300 600 300

1 600 1 -

Table 7-2

7.6

Interactive activities

7.6.1

Traffic Model For Internet Gaming

7.6.1.1 Online gaming Quality of Service (QoS) requirement In order to evaluate the impact of gaming data delay or gaming data loss to the quality of service of providing network gaming over wireless systems, it is necessary to define the QoS metrics for the game traffic model [18]. For car racing games, an average round trip time of 100ms is suggested [9]. Based on the work in [10] and a subjective quality assessment [11], an average round trip time of 139ms would provide sufficient game quality for first person shooter games like Counter Strike or Quake. Assuming 50ms average network delay and 30ms average downlink delay, the average delay for the uplink wireless air interface will be 59ms. In [10] and [9], it is observed that players experience serious degradation of game playability with a round trip delay of 200 - 225ms. To maintain the playability, a maximum delay of 145ms is applied to all data transfers, i.e., gaming data is dropped if it is not delivered after 145ms. There are very few statistics available for the tolerance of network/mobile gaming to data loss, partly because there is no clear threshold of data loss rate beyond which the game becomes unplayable. The playability of games decreases as the data loss rate increases. Page 37 (80)

WINNER

D1.3 v1.0

The topic of Game traffic model is relatively new and few literature exist on this issue. Nevertheless some important work exist as the first work on Source Models of Network Game Traffic by Borella [12] and the validation of the proposed traffic model on new evolved and more demanding versions of games in Network Game Traffic Modelling by Farber [10]. It is deemed valuable to report here below the associated state of art that may represent the basis for further analyses and for gaining a perspective of the possible future evolution of the recent successful gaming applications and of the associated traffic models. 7.6.1.2 Game traffic characteristics Among network games, action games are the most popular and within this genre the most popular game is Counter-Strike ® followed by Quake ®. A network game model for Counter-Strike is proposed in Network Game Traffic Modelling [10], which is an evolved model based on the network game model for Quake proposed in Source Models of Network Game Traffic [12]. Quake is a fast-action game in which a number of players each control a single character. The player traverses a highly graphical maze filled with weapons, ammunition and opponents. The goal for each player is to eliminate the other players as many times as possible. When players die, they are out of the game until they press a key and are resurrected. In Counter Strike, players join one of two teams and attack or defend against the other team. It is a very fast paced game where a player's life usually ends within a few minutes. The game communication model of both games follows the client/server approach and uses UDP packets for the exchange of small update information to maintain fairness of the game and player synchronization. The server sends game state information to each client where packets are read and processed. Clients synchronize the server game state with their local game state, process player commands, and return update packets with the players' movement and status information. Network game traffic generates a significant share of today’s Internet traffic. In [13] it is reported that 34% of all packets in a backbone could be associated with only 6 popular games. A high market potential, increasing usage as well as sharp real time requirements make this kind of traffic interesting for Internet service providers and manufacturers. In order to profit from the high popularity of online gaming, networks are enhanced for gamers, i.e. components and protocols are optimized for game traffic. In 1999 Borella presented a traffic model for the first person shooter “Quake 2“[12]. Since then many successful and more demanding multiplayer games have been developed. Although there are other popular online games emerging with more focus on strategy or role playing, first person shooters are still the most popular multiplayer games found in the Internet and they impose the hardest real time requirements on the network. Thus, in order to update the traffic model provided in [12], it has been chosen in [10] to characterize the traffic patterns of “Counter Strike“, a very popular first person shooter based on the Quake engine. In “Counter Strike“ a player partecipate to the game by joining one of two teams. The two teams attack or defend against each other. Player’s “life“ usually is very short and ends within few minutes. “Respawning“, i.e. re-entering the match with a new “life“, is not allowed until the next turn with a turn lasting at most 6 minutes. The games communication model follows the client server approach and uses UDP packets for the exchange of small update information. It has been monitored and registered game traffic over a LAN with 50 total participants for overall 36 hours. More precisely, several matches with 8 to 30 active players have been observed with the matches lasting from 30 to 90 minutes each (6.5 hours gaming in total). Details about such traffic observations and associated characteristics can be found in the Annexe 12.8. 7.6.1.3 Game Tr affic Model [10] provides a simple traffic model for fast action multiplayer games. Although multiplayer game traffic shows strong correlations due to a shared game state it has been shown in section Traffic Characteristics that the variance is small, i.e. these dependencies only lead to slight traffic changes. Thus, the game traffic can be modelled by independent traffic streams from each client to the server and a burst traffic stream from the server to the clients. Therefore the approach assumed in [10] is: (1) clients behave independent of each other, (2) server traffic per client is independent of the number of clients and (3) client traffic is independent of the corresponding server traffic. Based on the scope of the evaluation the modelled traffic only reflects active game phases without interruptions due to change of scenario or game options. During game interruptions client and server traffic may pause for a short time after which larger update packets are transferred to synchronize all clients. Note, that this traffic is not time critical. Those dynamics are out of the scope of this work and have to be modelled on a higher level if desired. the game traffic model proposed consists of only two independent modules, the client traffic model and the server traffic model with a burst size equal to the Page 38 (80)

WINNER

D1.3 v1.0

number of clients participating in the simulated traffic. For a mathematical description of the distribution functions for inter-arrival time or packet size it is necessary to find a function of similar shape and fit its parameters to the empirical data. As Borella [12] has identified the Extreme Value distribution to fit best for Quake traffic, also in [10] this function has been chosen for better comparison. Similar functions as shifted Lognormal or shifted Weibull lead to acceptable fits as well. The Extreme Value distribution is given by the following expressions:

F (X ) = e c

−e

−

X −a b

1 − f (X) = e b

X −a b

e

−e

−

X −a b

b>0

Server – Model The inter-arrival time for the server denotes the burst inter-arrival time. Within a burst a packet is sent to every client as soon as possible. Packet sizes are generated independently for each destination. Table 7-3 shows traffic characteristics of the observed data as well as the suggested distribution [10]. For matches with a small number of players it has been found that inter-arrival times of server bursts show four clear peaks comparable to client inter-arrival times, i.e. at 50 ms, 55 ms, 60 ms and 65 ms instead of a continuous distribution function as obtained for matches with many players. It has been assume that this behaviour is caused by the server nearing its performance limit in games with many clients. Client-Model As the distribution functions of client packet inter-arrival times is characterized by one to three peaks a multimodal distribution is suggested. Significant peaks are identified at 34 ms, 42 ms, 50 ms and 60 ms. As mo st observed clients show their peak at 42 ms it has been suggested a deterministic distribution for this inter-arrival time (see Table 7-3) [10]. Server (per Client) characteristic (burst) interarrival time Packet Size

peak = 55 ms mean = 62 ms coeff. of variation = 0.5 mean = 127 Bytes coeff. of variation = 0.74

approximation

Client characteristic mean = 41.7 ms coeff. of variation = 0.24

Deterministic (40 ms)

Extreme (a=55,b=6)

mean = 82 Bytes coeff. of variation = 0.123

Extreme (a=80,b=5.7)

Extreme (a=120,b=36)

approximation

Table 7-3 Counter Strike traffic characteristics and suggested approximation [10]

7.6.1.4 Use of Game Traffic Model The simplicity of the presented model allows to use it either to simulate traffic on a link to and from a subset of clients as well as traffic to and from the server communicating with all active clients. The number of active clients as well as session durations have to be set for the duration of the simulation or must be described on a higher model level, e.g. using the results of [14]. The game traffic model is not suited to provide background traffic for evaluations of other traffic flows. Its use is clearly in the evaluation of quality of service (QoS) aspects of networks in respect to games. In order to asses the impact of packet delay or packet loss experienced in a simulation, it is necessary to define QoS metrics for gaming applications. Today’s games can cope with an enormous lag (ping, round trip time) and loss. These applications are thought to be used over the Internet with a typical round trip time of 50 to 150 ms. If analogue modems are used, each use introduces an additional latency of 30 to 40 ms, i.e. an additional 120 to 160 ms to the round trip time for a dial-up player. Ping times frequently show 300 ms and more. Consideration of loss and lag are an essential part of the game design. Game designers try to optimize for 200 to 250 ms round trip time and provide robustness for larger lag. This is achieved by client-side Page 39 (80)

WINNER

D1.3 v1.0

prediction of the game state, i.e. movement of objects and other players [11][14]. By combining movement with inertia or reducing maximum velocity of objects prediction is even more effective. Such considerations result in very robust games tolerating lag up to one second and loss up to 40%. However, these values should not be taken as criteria for good or bad QoS since acceptable game play requires far better performance. Ping times of 50 ms or 150 ms make a huge difference. In [15] an evaluation of player effectiveness over that players ping time shows that players with lower ping times score significantly more kills than others. In a discussion on [16] players give comments on impact of ping times on game play. Some players report that they adapt their playing strategies to high ping times and may even enjoy a game with 200 ms lag. The impact of lag also depends on the game. As „Quake III Arena“ is very fast and responsive the ping time almost automatically decides on winning or losing. „Quake World“ or „Unreal Tournament“ are reported to behave much better in this regard, i.e. ping times are not as decisive for successful playing. Based on [17] and [16] we find that a ping below 50 ms is associated with excellent game play. A ping below 100 ms is good and above that, playability decreases noticeably. Ping times above 150 ms are often reported to be intolerable but many players claim to have no problems with ping times around 200 ms. An evaluation on „Half Life“ reported in [17] shows that players who experience high ping times of over 225 ms do not quit and look for a faster server but stay and continue to play with this high lag. It has been assumed that those players use 56k modems and do not expect to get a better connection elsewhere. The study reveals that many gamers (40%) play with a high lag of over 225 ms despite of the decreased playability. The impact of packet loss is rarely discussed as it is experienced as lag as well. However, a high ping time without packet loss is preferable to a small ping time with packet loss of around 10%. 7.6.1.5 Future Mobile Gaming Applications QoS metrics According to the above discussion it is expected that future wireless mobile systems can assure high quality as for lag (ping, round trip time). Currently understanding is that 50 ms lag is considered excellent quality while 100 ms lag is considered good quality: future wireless system networks should be able to achieve such lag range (50 – 100 ms) target. While on the issue of the impact on QoS of the lag some understanding has been gained trough previous works, there are very few statistics available for the tolerance of network/mobile gaming to data loss, partly because there is no clear threshold of data loss rate beyond which the game becomes unplayable. Apart form the obvious consideration that the playability of games decreases as the data loss rate increases, there is the need for collection of statistics and users feedback on this issue. It is expected that the increase in complexity of games may lead to a further need of data loss control and low data loss may become a key parameter of the mobile games QoS metrics.

7.6.2

Telesurgery

The last couple of years, several institutes and organizations around the world are investing in telesurgery. It is definitely something futuristic and most people are very cautious with such developments, however, there is strong belief that telesurgery can become a very important medical science in the forthcoming years. This will be assisted by the rapidly developed ICT technologies, including landline and wireless systems. History of telesurgery and major achievements are annexed in section 12.6. 7.6.2.1 Requirements for a wireless System Beyond 3G Given the experience from the Telesurgery attempts so far, following requirements can be derived: Broadcast-quality video IP telephony Videoconferencing LAN interconnection End-to-end Quality of Service It is difficult at this moment to provide concrete information about datarates, delay, etc, it is however possible to match these requirements with pre-defined Service Classes, as those presented bellow. Service Class

Data Rate

1. Real time collaboration and gaming

1-10 Mbps (proposed 1-20 Mbps)

2.

30-50 Mbps

Geographic

Traffic type SERR

Delay

SERR

Highly Interactive

Highly Interactive

Error Rate 1.00E-0.6 1.00E-0.9

1.00E-0.6

Applications Telepresence/Videoconference Collaborative work Navigation systems Real-time Gaming High quality/3D telepresence Page 40 (80)

WINNER real datacast

time

D1.3 v1.0 (proposed 20-50 Mbps)

1.00E-0.9

/Videoconference/ Collaborative work/ systems (3D-VR)

Navigation

5. Interactive high multimedia

2-5 Mbps

SERR

Interactive/Control

1.00E-0.6

Rich data call Control Video broadcasting/streaming Robot security High quality video conference Collaborative work

7. Interactive ultra high multimedia 8. Simple telephony and messaging

10-50 Mbps

SERR

Interactive/Control

1.00E-0.3 1.00E-0.6

8-64 kbps

SERR

Conversational

1.00E-0.3 1.00E-0.6

11. Rich data and media telephony 12. LAN access and file service 17. High quality video streaming

2-5 Mbps

SERR

Conversational

1.00E-0.3 1.00E-0.6

Up to 50 Mbps

SYSA

Conversational

1.00E-0.6

Voice telephony Instant messages Lightweight multiplayer games Bets and gambling High quality video telephony Collaborative work Standard data call Access to databases, filesystems,

30 Mbps

SERR

Few Seconds

1.00E-0.9

Video streaming (archival)

Table 7-4 Service Classes for Telesurgery application 7.6.2.2 Traffic models In the previous sections the fundamentals of Telesurgery were presented, as well as the requirements for wireless Telesurgery and the associated Service Classes. Concerning the traffic models that describe the whole application, these are the group of known models that characterize each of the services provided during a TeleSurgery. Broadcast-quality video: This is required, since the image should be broadcasted securely to remote place, so that the doctor can see all details needed. The traffic model for the broadcast-quality video is the one described in 7.1.2 as video streaming. IP telephony: IP telephony is required for communication purposes.The traffic models that have the widest adoption are Erlang B, Extended Erlang B, and Erlang C. Other commonly adopted traffic models are Engset, Poisson, EART/EARC, and Neal-Wilkerson. A comparison of traffic model features is shown in Table 7-5. [24] Traffic Model

Sources

Arrival Pattern

Poisson Erlang B Extended Erlang B Erlang C Engset EART/EARC Neal-Wilkerson Crommelin Binomial Delay

Infinite Infinite Infinite Infinite Finite Infinite Infinite Infinite Finite Finite

Random Random Random Random Smooth Peaked Peaked Random Random Random

Blocked Call Disposition Held Cleared Retried Delayed Cleared Cleared Held Delayed Held Delayed

Holding Times Exponential Exponential Exponential Exponential Exponential Exponential Exponential Constant Exponential Exponential

Table 7-5 Traffic Model Comparison Videoconferencing: For medical meetings and decisions by a number of doctors. LAN interconnection: In order to allow full control of equipment form a remote place. The traffic model that describes the LAN interconnection is TCP/IP, described in section 7.4.

Page 41 (80)

WINNER

7.6.3

D1.3 v1.0

Telepresence

Telepresence, or the projection of the human sensory apparatus into a remote location, can provide scientists with a much greater intuitive understanding of the environment in which they are working than simple camera -display systems. Likewise virtual reality, or the use of highly interactive three-dimensional computer graphics, can both enhance an operator's situational awareness of an environment and also compensate (to some degree) for low bandwidth and/or long time delays in the communications channel between the operator and the vehicle.[25]. Key projects are annexed in 12.7. 7.6.3.1 Application requirements The major concern for this interactive application is the understanding of the technical requirements on computing and telecommunication needed to support a sense of group telepresence among separated workers. In the “Ontario Telepresence Project”, a team of top-notch sociologists, psychologists, computer scientists and engineers in academia and industry was assembled and separated them geographically. Then one of the most advanced human-computer interaction research test-beds in the world was built. Over the years, dozens of hardware and software prototypes were developed, using ISDN and ATM connections to support video, audio and data connections between cities and across the Atlantic. Numerous prototype systems in field trials were studied. One of the most important conclusions emerging out of this multi-disciplinary team of experts was that background awareness was an essential part of the cohesion of work groups and that this awareness supported effective communication and interaction between individuals, even if they were geographically separated. [27] The major telecommunication requirements depend on the type of telepresence application. Some application require high bandwidth, so that video can also be transmitted, while other are running with lower data rates. Delay is another important factor that should be within acceptable levels, again depending on the application. Summarizing the major telepresence services, following applications are utilized: Videoconference Collaborative work Navigation systems Remote control Presence driven transfer Multiplayer games 7.6.3.2 Telepresence Traffic models The traffic models that describe this group of applications are listed bellow: • Videoconferencing • IP Telephony • Broadcast-quality video • Internet gaming • TCP/IP traffic

7.7

TCP – IP

The Winner project assumes the usage of IP protocols. As a consequence it is appropriate to evaluate the impact of such protocols on the traffic models introduced in the previous chapters in terms of overhead. The purpose of this section is to propose preliminary models and draw first conclusions on the overhead introduced by the IP protocols suite. A report on the SoA and current understanding of the IP protocols suite with, in particular, introduction to the major evolution trends as IPv6 and Mobile IP is provided in the Annex.

7.7.1

TCP/IP Overhead

Overhead refers to the additional information (transmission bandwidth) necessary to transmit the same amount of information, due to the particular network protocol used. When a packet, that for instance contains part of an image, is sent on a network, with the TCP/IP protocol there is always a preamble (header) containing the destination address and other information. The quantity of overhead presents in a TCP/IP transmission varies according to different factors as the MTU size and the length of the information (Data) to transfer. First of all we can discuss the overhead

Page 42 (80)

WINNER

D1.3 v1.0

models separately for the two versions of IP, IPv4 and IPv6, introduced. It is clear that in perpesctive, in the Winner context, IPv6 should be adopted as benchmarking reference protocol. IPv4 Overhead Two cases can be distinguished, No Fragmentation and Fragmentation: •

•

No Fragmentation: in this case the TCP segment that is delivered to the underlying level, from the transport level to the internet level, with the addition of the IP header (20 Byte) results to be ≤ of the MTU of the net. Then the overhead is: OVERHEADTOT

= OVERHEADTCP + OVERHEADIP = = HEADERTCP + HEADERIP = = 20 Byte + 20 Byte = 40 Byte

OVERHEADTOT%

= (OVERHEADTOT / DATA) *100= = (20Byte / DATA) * 100

Fragmentation: Fragmentation: the TCP segment that is delivered to the underlying level, from the transport level to the internet level, with the addition of the IP header (20 Byte) it results to be > of the MTU size of the net. Then it is necessary a fragmentation of the IP packet in N fragments: Z

=(DATA + OVERHEADTCP ) / (MTU – OVERHEADIP )= =(DATA + HEADERTCP ) / (MTU – HEADERIP )= =(DATA + 20 Byte) / (MTU – 20 Byte)

N

= [Z] (N = Z rounded to the superior integer)

OVERHEADTOT

=OVERHEADTCP + N * OVERHEADIP = =HEADERTCP + N * HEADERIP = =20Byte + N * 20Byte= =20Byte * (N+1)

OVERHEADTOT%

= (OVERHEADTOT / DATA) *100= = ((20Byte * (N+1)) / DATA) * 100

IPv6 Overhead Also in this case we can separate the discussion in two cases, No Fragmentation and Fragmentation: •

No Fragmentation Minimum Overhead: Header TCP + Header IP (no extension header) OVERHEADTOT = OVERHEADTCP + OVERHEADIP = = HEADERTCP + HEADERIP = = 20 Byte + 40 Byte = 60 Byte OVERHEADTOT%

•

= (OVERHEADTOT / DATA) *100= = (60 Byte / DATA) * 100

Fragmentation Overhead with Fragmentation: + 8 Byte (Fragment Header) Z =(DATA + OVERHEADTCP ) / (MTU – (OVERHEADIP + OVERHEADFrag.))= =(DATA + HEADERTCP ) / (MTU – (HEADERIP + HEADERFrag.))= =(DATA + 20 Byte) / (MTU – 48 Byte) N

= [Z] (N = Z rounded to the superior integer)

OVERHEADTOT

=OVERHEADTCP + N * (OVERHEADIP + OVERHEADFrag.)= =HEADERTCP + N * (HEADERIP + HEADERFrag. ) =20 Byte + N * 48 Byte

OVERHEADTOT%

= (OVERHEADTOT / DATA) *100= = (20 Byte + N * 48 Byte) / DATA) * 100 Page 43 (80)

WINNER

D1.3 v1.0 The above has to be interpreted as minimum overhead. The actual overhead depends in IPv6 from options used in the extension header.

IP Overhead Modelling The above models provide an estimation of the Overhead introduced by IPv4 and IPv6. The overhead introduced results in additional information that need to be generated and transmitted together with the original user data. This means that such overhead results in an overall data transmission increase factor (Overhead percentage) that need to added to the original estimation of user data generation typically model by traffic models (see previous chapters). As discussed above two models are possible depending on the size of the underlying MTU size, No-Fragmentation and Fragmentation models. The MTU size depend from the specification of the underlying levels (MAC layer) that is under discussion in other WPs (WP2 and WP3) and therefore is out of the scope of WP1 activity. Nevertheless it is suggested to apply the most conservative model (greatest overhead) represented by the Fragmentation models. Considered the evolution trends of IP towards IPv6 the final general proposed model for IP layer in the context of Winner is the one corresponding above to the IPv6/Fragmentation case.

8.

Conclusion

This document gives the final usage scenarios after refinement work where feedback from other groups and internal iteration has been taken into account. The major achievements have taken in place in defining the service classes and usage scenarios that now represent very mature outcome of the group work. The number of service classes is 18 (Table 3-1), which highlights the fact that a WINNER system is very versatile and should be capable of serving many applications and type of services in various user scenarios. The document also gives a reduced set of service classes (as response to requests from other work packages) but with a clear warning of the pitfalls its use may lead to. The usage scenarios have led to a final outcome for generic applications grouping. Now there are nine major groups that are divided into a fine structure of 24 subgroups. Some examples of typical scenario elements have been included into this document while more comprehensive treatment can be found in earlier documents D 1.1 [1] and D 1.2 [2]. Chapter 5 of the current document gives an initial analysis of WINNER system concept in view of the WP1 scenarios. Since at this stage the WINNER project has not yet finalized a stable definition of WINNER system concept, the analysis of the WINNER system concept versus WP1 scenarios at this stage is at a very initial state. The first remarks are made and no red flag fo r WP1 scenarios appears at this point. Nevertheless, the analysis of the impact ad coherence of the WINNER system concept on the WP1 scenarios, as it will become more and more defined during the current evolution of the project, will need far more discussion, clarifications and work: such task is expected to be one of the major WP1 activities in the final part of the current year. Chapter 6 opens a new field: business and economic analysis. The basis is defined and set for later work. The main part of work in this area has been allocated for phase 2 of WINNER (starting year 2006). Traffic models are given and discussed in chapter 7. These include "evolved models" (extracted and modified for WINNER use) and new ones; evolved models discussed are Internet/Browsing, Conversational Voice, Video and Audio Streaming, File Transfer; new models address mainly Interactive applications. Basics of TCP-IP are given for future reference. Also estimations and models of IP protocol suite overhead are provided. The area of analysis and development of traffic models is potentially highly time and resource consuming. Therefore, in this area in particular, WP1 has experienced shortage of resources and it may be that these could be updated should new information become available, e.g. from other WPs. The scenarios have been finalized, a comprehensive list of service classes is now available and topics of system concept comparison and business analysis have been opened. For traffic models the group has now given a set of models that can be used for various analyses. Next steps will be creating the final requirements based on the basis of this document.

Page 44 (80)

WINNER

9.

D1.3 v1.0

References

[1] WINNER deliverable D1.1, “First Economic and Technical Evaluations per Scenario” [2] WINNER deliverable D1.2, “Intermediate requirements per scenario" [3] E. Mino Diaz, D. Noguet, et al, “4G scenarios and system requirements”, 30th April 2003. IST-200138354 STRIKE D2.1 [4] C802.20-03/43, “802.20 Evaluation Methodology Strawman (03/57 is ppt)”, IEEE 802.20 May 2003 Session. [5] 1xEV-DV Evaluatuion Methodogy, 3GPP2/TSG-C.R1002. Document available in 802.20 drop-box. [6] D. Staehle et al, “Source Traffic Modeling of Wireless Applications,” Research Report, June 2000. available at: http://www3.informatik.uni-wuerzburg.de/TR/tr261.pdf [7] RFC 959, http://www.faqs.org/rfcs/rfc959.html [8] S. Ladha, P. Amer, “Improving File Transfer Unsing SCTP Multis treaming” [9] Lothar Pantel, and Lars C. Wolf, "On the impact of delay on real-time multiplayer games", Proceeding of the 12th International Workshop on Network and Operating Systems Support for Digital Audio and Video, 2002 [10] Johannes Farber, "Network Game Traffic Modelling", Proceedings of the first workshop on Network and system support for games, 2002 [11] Christian Schaefer, Thomas Enderes, Hartmut Ritter, and Martina Zitterbart, "Subjective quality assessment for multiplayer real-time games", Proceedings of the first workshop on Network and system support for games, 2002 [12] Michael S. Borella, "Source Models of Network Game Traffic", Computer Communications, 403 410, Feb. 15, 2000 [13] McCreary S., claffy k.: Trends in wide area IP traffic patterns - A view from Ames Internet Exchange, ITC Spec. Seminar, 2000 [14] Henderson T., Bhatti S.: Modelling user behaviour in networked games, Multimedia 2001, June 2001, http://www.acm.org/sigs/sigmm/MM2001/ep/henderson/ [15] Armitage, Grenville: Sensitivity of Quake3 Players To Network Latency, IMW2001 workshop poster session, Nov 2001, http://www.geocities.com/gj_armitage/q3/quake-results.html [16] Slashdot, How Fast Too Slow? A Study Of Quake Pings, discussion forum, May 2001, http://slashdot.org/article.pl?sid=01/05/24/ 204423 [17] Trier M.: Highspeed-Internet, GameStar (Gaming Magazine), March 2002, pp.164-165 [18] http://www.nokia.com [19] www.bjhc.co.uk/news/1/2004/n41204.htm [20] http://enterprise.bell.ca/en/resources/success/default.asp?sid=26&did=455 [21] http://www.eits.org/ [22] http://www.radcatel.com/Article/0,6583,15730,00.html [23] http://www.radcatel.com/Article/0,6583,19902,00.html [24] http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a00800d6b74.shtml# 53506

[25] http://www.ri.cmu.edu/pubs/pub_2797.html [26] http://www-cdr.stanford.edu/telepresence/VSEL.html [27] http://www.telepres.com/less_is_more.shtml [28] “An Introduction to MPEG Video Compression”, by John Wiseman [29] G. Iacovoni, S. morsa, D. Parisi, D. Pierotti, “Broadband FRA scenario and traffic modeling,” 15th April 2002, IST-1999-11571 EMBRACE D 22 [30] A.Mena, J.Heidemann, “An Empirical Study of Real Audio Traffic”, Proceedings of IEEE INFOCOM, Tel Aviv, Israel, March 2000 [31] http://www.mobilevce.com/ [32] Video Communications and Video Streaming – John G. Apostolopoulos – Streaming Media Systems Group – 2002, pag. 13.

Page 45 (80)

WINNER

D1.3 v1.0

10.

Annex – Scenario generation and analysis procedure

10.1

Scenario generation and analysis procedure

This chapter presents an overview of the methodology followed to generate and analyse the scenarios and the different steps of this generation. Users + Motivations

External Scenarios

External Traffic Models

[Winner] User Scenarios [Winner] Traffic Models

External Technological Trends

Analysis Service Context Technology Context User Conte xt

Service Classes Generic Applications

Usage Scenarios

Grouping + Selection

External inputs

Most Promising

Achievements

Performance Req.

The scenario elements are identified for certain user groups combined to their fundamental motivations. Then these scenario elements are grouped by generic application type and analysed to develop initial service classes. Further generalisation and consolidation leads to a more refined and organised set of service classes. Additional background detail on the methodology is available in WINNER Deliverable D1.1 [1].

10.1.1 Methodology to identify scenario elements Given the diverse range of users and converging markets of relevance to WINNER, it was necessary to develop an efficient mechanism to create useful scenarios which are both realistic and challenging. The methodology that was chosen made use of the existing body of knowledge in these areas, and identified the relevant components that could be integrated to create new scenarios targeted for the WINNER project. Three dimensions were combined to achieve the required results: • External reference scenarios • Motivations • User categorisation There were three different approaches to identifying external reference scenarios, namely: • Evolutionary - based on extrapolation of current trends and developments within the mo bile and wireless domain • ”Dreams” - based upon visionary and revolutionary considerations • Analogies - consideration of current and near future development in other related domains, such as fixed Internet, networked gaming etc. By predicting the motivations and users with most relevance to the WINNER project, the external reference scenarios were analysed to identify scenario elements. These correspond to specific instances of fulfilment of the user motivations. The WINNER ubiquitous radio system concept should fulfil the requirements of these scenario elements. The following table presents those combinations of users and motivations which were used for scenario element identification. The full set of users and motivations is presented in Deliverable D1.1 [1]. Page 46 (80)

WINNER Old:

D1.3 v1.0 "Culture" "Entertainment" "Healthcare" "Identity" & "Sharing Experiences" "Individuality and Family" "Community" & "Synchronisation" "Instruction/Control"

Youth:

&

"Reassurance

&

Security"

"Fixed/wired Substitution" & "Community" & "Identity" & "Individuality and Family" "Communications" "Diversion/Distraction" "Emotion" "Entertainment" "Fashion/Trend/Keeping

Business

Up"

"Authentication" "Commerce" & "Transaction" "Competition" "Freedom, Mobility" "Individuality and Family" "Navigation" "Presence/Availability Signalling" & "Time/Location/Context" "Reference/Data" "Security" "Synchronisation

Remote worker

(both

life

and

data)"

"Authentication" & "Security" "Cooperation" "Freedom, Mobility" "Presence/Availability Signalling" & "Time/Location/Context" "Reference/Data" "Synchronisation

Tourist

(including

group)"

"Alert/Warning" & "Security" "Augmentation (Reality)" "Commerce" "Culture" "Freedom, Mobility" "Navigation" "Reference/Data" "Sharing Experiences" "Time/Location/Context"

Page 47 (80)

WINNER Emergency/healthcare organization

D1.3 v1.0 "Alert/Warning" & "Assistance" & "Augmentation (both)" "Instruction/Control" & "Presence/Availability Signalling" "Time/Location/Context"

& &

"Audit Trail" "Communications" "Navigation" "Reference/Data" "Save Time" "Security"

Script scenarios, such as a day in the life of a particular user, or a location, or an event, were developed in Deliverable D1.1 [1], and allow a more coherent presentation of some of the scenario elements, and the opportunity to perform a more in depth analysis of a subset of the possibilities. In particular, such analysis is useful at the higher level, considering the overall values of the Wireless World. Such an analysis was done within the WWI Cross Issue on User Requirements, resulting in a consolidated set of WWI scenarios, including the day in the life of a Young Person, sourced from the WINNER project.

10.1.2 Scenario analysis procedure and generic application types Since there are already a large number of scenarios which describe views of future services and applications, a process was chosen which would make use of the existing resources. In order to overcome the problem of disparate timescales of development, the first step was to consider user activities from a higher level of abstraction. Rather than focussing on the services and applications, what are the fundamental motivations and needs which exist for users? These tend to have very small temporal variation – even over much longer time periods than those of interest for new air interface development. By identifying the key motivations for some of the more interesting user types, where a user may be an individual, a group, or an organisation, it was possible to identify those components within different existing scenarios which showcase activities which fit to the assumptions and underlying landscape of the WINNER project. Having identified these components, which we refer to as scenario elements, the first step towards the service context table is to group them around the application type. Only the most representative scenario elements have been selected for each application type. The following list shows examples of the application types which were used to group those scenario elements that have been analysed in the service context table. The selected scenario elements for each application type represent different variants of that application type, such as high quality, interactive,… • • • • • •

Voice Telephony LAN Access Network games Navigation and guidance Collaborative work Telepresence

The service context table which is presented in section 4.1 of Deliverable D1.1 [1] is an analysis of the representative scenario elements in terms of service level characteristics, such as required data rate, or amount of data, delay and variation, permissible error ratio, termination points (point to point, point to region etc.), context derivation, and service discovery/set up time, which have some relation to the air interface requirements. A synthesis of the service context table has been made across two main axes: data rate and delay. Two additional dimensions have been identified: error rate and traffic type. The traffic type describes qualitatively the bit rate and also explains if the transmission should be from point to point (or multipoint) or from point to region.. The result of this synthesis is the table of initial service classes which covers the range of all the identified scenario elements. They were presented in section 5 of Deliverable D1.1 [1]. Following the generation of initial service classes, a number of steps have been taken to refine and consolidate these service classes. Page 48 (80)

WINNER

D1.3 v1.0

By considering which generic applications are supported by which service classes it has been possible to identify those service classes which support the same generic applications, or where all of the generic applications supported by one service class are also supported by one or more of the other service classes. In this manner it has been possible to identify a small number of service classes which become redundant in the presence of the other service classes, or which can be merged into a single service class. Further generalisation and grouping of the application types used to choose and group scenario elements provides an opportunity to identify commonality between service classes across previously distinct application types, again leading to reduction or merging of service classes. The final step in service class refinement has been to explore different ways of grouping service classes. In the same way that identification of commonality across application types has allowed some refinement of the service classes, exploration of commonality in other domains (for example, whether classes support one-way, two-way or multi-way communication) has also been used. These analyses are performed on generalised abstractions of the scenario elements, since the goal of WINNER is not to support specific services or applications, but rather to provide a flexible range of capabilities which can be used to support a diverse range of services and applications, as may become available in the future.

10.2

Further steps in the Methodology and analysis.

Two main steps in the analysis remain, beyond those already ongoing:

10.2.1 Business and Economic analysis The developed service classes, and their underlying application support, must be analysed for business and economic validity, and requirements. Is there a possible business case (or does there need to be, in the case of “value add” services), and what economic constraints would there be on the cost of providing these services profitably?

10.2.2 Translation of Service requirements into Radio Access System requirements In order to be fully utilised in complete WINNER system evaluations, it is necessary to translate the service level requirements into radio access system level requirements, and link level requirements. In some cases this may be a trivial exercise – for example the link level (user) data rate to carry a particular service class can be the same as the service level data rate, provided the link is only carrying a single service. Other requirements rely on a combination of analyses and characteristics of the proposed system – for example, required cell capacity is a function of the density of users, their service mix and usage characteristics, and the coverage area of the cell.

Page 49 (80)

WINNER

11.

D1.3 v1.0

Annex - Service Clases Grouping

11.1.1 One, two, multi-way communication The characteristic of “One, two, multi-way communication type” intends to indicate the nature of the communication as far as the directions that the communication is concerned. Three groups are identified, namely the Point to Point monodirectional (uplink or downlink) (one-way) or bidirectional (uplink and downlink) (two-way) or Point to Multi-Point, Multi-Point to Multi-Point, Multi-Point to Point (multiway). The resulting grouping is as follows: One-way communication 3. Short control messages and signalling 13. Multimedia messaging 15. File exchange 16. Video streaming 17. High quality video streaming 18. Large files exchange Two-way communication 4. Simple interactive applications 8. Simple telephony and messaging 11. Rich data and media telephony 12. LAN access and file service 14. Lightweight browsing Multi-way communication (one to multi, multi to multi, multi to one) 1. Real time collaboration and gaming 2. Geographic real time datacast 5. Interactive high multimedia 6. Geographic interactive multimedia broadcast 7. Interactive ultra high multimedia 10. Geographic datacast

11.1.2 Media and data The characteristic of “Media and data content type” permits grouping according to the most typical content type of the service classes. Two main groups are identified, namely the Media and the Data content types. The resulting grouping is as follows: Media 1 Real time collaboration and gaming 13 Multimedia messaging 4 Simple interactive applications 5 Interactive high multimedia 6 Geographic interactive multimedia broadcast 7 Interactive ultra high multimedia 8 Simple telephony and messaging 9 Data and media telephony 11 Rich data and media telephony 16 Video streaming 17 High quality video streaming Data 2 Geographic real time datacast 10 Geographic datacast 12 LAN access and file service 3 Short control messages and signalling 14 Lightweight browsing 15 File exchange Page 50 (80)

WINNER

D1.3 v1.0

18 Large files exchange

11.1.3 Degree of interactivity The characteristic of “Degree of interactivity” permits grouping according to the type of interactivity corresponding to each service class. Three main groups are identified, namely the Asymmetric interactivity group, the Symmetric interactivity group and the No/Low interactivity group. The resulting grouping is as follows: Asymmetric interactivity 3 Short control messages and signalling 4 Simple interactive applications 5 Interactive high multimedia 6 Geographic interactive multimedia broadcast 7 Interactive ultra high multimedia 13 Multimedia messaging Symmetric interactivity 1 Real time collaboration and gaming 8 Simple telephony and messaging 9 Data and media telephony 11 Rich data and media telephony 12 LAN access and file service No/Low interactivity 2 Geographic real time datacast 10 Geographic datacast 14 Lightweight browsing 15 File exchange 16 Video streaming 17 High quality video streaming 18 Large files exchange

11.1.4 Source to destination The characteristic of “Source to destination communication type” identifies possible sources and destination type of communications. Three main groups are identified, namely the Person to Person group, the Person to Machine (and vice versa) group and the Machine to Machine group. The resulting grouping is as follows: Person to person 1 Real time collaboration and gaming 5 Interactive high multimedia 7 Interactive ultra high multimedia 8 Simple telephony and messaging 9 Data and media telephony 11 Rich data and media telephony 15 File exchange 16 Video streaming 17 High quality video streaming 18 Large files exchange Person to machine (and vice versa) 1 Real time collaboration and gaming 2 Geographic real time datacast 3 Short control messages and signalling 4 Simple interactive applications 5 Interactive high multimedia 6 Geographic interactive multimedia broadcast 7 Interactive ultra high multimedia 8 Simple telephony and messaging 9 Data and media telephony 10 Geographic datacast Page 51 (80)

WINNER

D1.3 v1.0

11 Rich data and media telephony 12 LAN access and file service 13 Multimedia messaging 14 Lightweight browsing 15 File exchange 16 Video streaming 17 High quality video streaming 18 Large files exchange Machine to machine 3 Short control messages and signalling 4 Simple interactive applications 5 Interactive high multimedia 10 Geographic datacast 12 LAN access and file service 13 Multimedia messaging 15 File exchange 16 Video streaming 17 High quality video streaming 18 Large files exchange It may be interesting to consider further refinement of this grouping section, considering when it would also make sense for Agents (a form of machine) to replace People. (e.g. also include person-agent, agentagent, agent-machine, or just include examples including agents within the current groupings). Although there is a large overlap between these groups, which limits their utility in direct revision of the service classes, this analysis may still be useful. In particular, when considering device classes and linked capabilities, it is expected that many devices will not need to support all the service classes, and a grouping such as this may be of assistance in identify which support is needed.

11.1.5 Symmetry The characteristic of “Symmetry” permits grouping of service classes according to symmetry in the uplink/downlink communication link characteristics. Three specific symmetry types are identified, namely the Symmetry according to Data Rate, Symmetry according to Data Size and Symmetry according to QoS. Splitting of types according to symmetric or asymmetric characteristics gives origin to six groups. The resulting grouping is as follows: Symmetric Data Rate Low Data Rate (8 – 512 kbps) 8 Simple telephony and messaging 9 Data and media telephony Medium Data Rate (0.512 – 10Mbps) 1 Real time collaboration and gaming 11 Rich data and media telephony High Data Rate (above 10 Mbps) 7 Interactive ultra high media Asymmetric Data Rate Low Data Rate (8 – 512 kbps) 3 Short control messages and signalling 4 Simple interactive application 14 Lightweight browsing 13 Multimedia messaging Medium Data Rate (0.512 – 10Mbps) 2 Geographic real time datacast 7 Interactive high multimedia 6 Geographic interactive multimedia broadcast Page 52 (80)

WINNER

D1.3 v1.0

15 File exc hange 16 Video streaming High Data Rate (above 10 Mbps) 12 LAN access and file service 17 High quality video streaming 18 Large file exchange Symmetric Data Size 1 Real time collaboration and gaming 5 Interactive high multimedia 7 Interactive ultra high media 8 Simple Telephony and messaging 9 Data and media telephony 11 Rich data and media telephony 12 LAN access and file service 13 Multimedia messaging 15 File exchange 18 Large file exchange Asymmetric Data Size 2 Geographic real time datacast 3 Short control messages and signalling 4 Simple interactive application 6 Geographic interactive multimedia broadcast 10 Geographic Datacast 14 Lightweight browsing 16 Video streaming 17 High quality video streaming Symmetric QoS 1 Real time collaboration and gaming 3 Short control messages and signalling 5 Interactive high multimedia 6 Geographic interactive multimedia broadcast 7 Interactive ultra high media 8 Simple Telephony and messaging 9 Data and media telephony 11 Rich data and media telephony 12 LAN access and file service 13 Multimedia messaging 14 Lightweight browsing 15 File exchange 18 Large file exchange Asymmetric QoS 2 Geographic real time datacast 4 Simple interactive application 10 Geographic Datacast 16 Video streaming 17 High quality video streaming Some preliminary considerations can be developed by the analysis of the service classes according to the Symmetry characteristics. Additional groups may be considered as analysis of symmetry according to additional features (e.g. Duty Cycle). It is deemed anyway that the three considered features, Data rate, Data size and QoS, are adequate to start an initial analysis. Analysis of symmetry in data rates leads quite naturally to the consideration of three categories as for data rates (outlined in the above list) and data size: low, medium and high data rate and data size. Service classes should therefore probably be classified and organized in order to allow such multiple cases. The same remark applies to the QoS features taking into account the initially considered cases (BER 10-3 , 10-6 , 10-9 ). Grouping according to the three mentioned levels should be completed also for Data Size and QoS Symmetry grouping. An overall revision/organization of service classes capable to reflect the above structure may be required.

Page 53 (80)

WINNER

D1.3 v1.0

11.1.6 Mobility and Range The characteristic of “Mobility and Range” permits to classify services classes according to the characteristics of support of Mobility and Range. Four main groups are identified, namely the Low Mobility/Short Range group, the Low Mobility/General Range group, the General Mobility/Short Range group and the ”Anything” (high or low velocity, long or short distance) group The resulting grouping is as follows: Low mobility, short range 1 Real time collaboration and gaming 12 LAN access and file service 7 Interactive ultra high multimedia Low mobility, general range 5 Interactive high multimedia 15 File exchange 17 High quality video streaming 18 Large files exchange General mobility, short range, 2 Geographic real time datacast 6 Geographic interactive multimedia broadcast 10 Geographic datacast Anything (high or low velocity, long or short distance) 8 Simple telephony and messaging 3 Short control messages and signalling 4 Simple interactive applications 9 Data and media telephony 11 Rich data and media telephony 13 Multimedia messaging 14 Lightweight browsing 16 Video streaming It should be noted that this grouping may include technology limitations inherited from today's capabilities. While these may not be real usage limitations they may give indications to the possible areas where compromises could be made, if absolutely necessary. The division given here should be read that viewpoint in mind and not as a definite user requirement.

11.1.7 Granularity The classification upon the characteristic “Granularity” is intended to identify which service class can lead to transport inefficiencies due to a mismatching of the delivered packet size to the transmission parameters. Worst case is an uplink transmission demanding small packets. This classification can be used to collect information when designing some encapsulating units used in transmission. As an example, the total amount of services demanding short/long packets or the proportion of them on the total might influence the decision of physical and MAC layer granularity. Parameters, which eventually might be limiting or limited are MSDU and other MAC fragmentation units, and physical layer packet size. The resulting grouping is as follows: Low granularity (Long data packets) 1 Real time collaboration and gaming 2 Geographic real time datacast 5 Interactive high multimedia. 6 Geographic interactive multimedia broadcast 7 Interactive ultra high multimedia. 9 Data and media telephony 10 Geographic datacast 11 Rich data and media telephony 12 LAN access and file service 15 File exchange 16 Video streaming Page 54 (80)

WINNER

D1.3 v1.0

17 High quality video streaming 18 Large files exchange Medium granularity (Medium size data packets) 4 Simple interactive applications 8 Simple telephony and messaging 14 Lightweight browsing High granularity (Short data packets) 3 Short control messages and signalling 13 Multimedia messaging

Page 55 (80)

WINNER

D1.3 v1.0

12.

Annex - Traffic Models

12.1

Internet/Browsing

The Internet represents the largest existing WAN offering a broad spectrum of information resources in form of technical reports, product information, software, images, audio and video sources and electronic commerce services. The popularity among larger user groups to use these resources were driven by the introduction of the WWW. In the WWW, global naming conventions, protocols and object formats are used. An object can be a text file, an Audio source, an image file or even the code of a program that can be interpreted and executed on the user's terminal (Java applet). A WWW browser displays WWW pages that are composed of one or more WWW objects Figure 12-1 shows a WWW page displayed by a WWW browser. It contains several different objects such as text and images. Within one page links can be defined that are connected to an identifier of a WWW resource, a URL. When the user chooses a link, a new object or page is displayed. By the direct specification of a URL in the text field of the WWW browser, a specific page or object can be chosen by the user (see Figure 12-1). Every object of the WWW has a unique URL. The presentation of a WWW page is described by the HTML. In an HTML file the appearance and the URL of the contained objects are specified. An HTML page can also contain text that is displayed at the related position of the page. An HTML page itself is also a WWW object that is analysed by the browser. Further WWW objects are specified in the HTML file as part of the page that are requested and transmitted.

Figure 12-1: Structure of a WWW page

The WWW is characterized by a client-server architecture. A WWW browser represents a client that poses requests to a WWW server concerning the transmission of WWW objects that are stored on the server. The communication between client and server is controlled by HTTP. HTTP is an application oriented protocol that uses the TCP for end-to-end transport. In the initial version of HTTP a new TCP connection is set-up for each requested object. The client transmits a request for a certain object to the server. The request contains the URL of the object, data format parameters and parameters for access control. The server processes this request and transmits the requested object to the client. Then the TCP connection is released. In newer HTTP versions, e.g., HTTP version 1.1, TCP connections can be reused by the following objects (persistent TCP connections) and several TCP connections can be set-up in parallel used for the pipelined transmission of several different objects (pipelined TCP connections). Figure 12-2 depicts the sequence of a WWW session.

Page 56 (80)

WINNER

D1.3 v1.0

Figure 12-2: Sequence and parameters for a WWW session

Choi's behavioural model is representative for WWW browsing performed on 2 PC connected to the fixed Internet. As mentioned above WWW sessions consist of requests for a number of pages. These pages consist of objects, each with a certain object size. Another characteristic parameter is the delay between two pages depending on the user's behaviour to surf around the Web (see [Choi99]). Table 12-1 gives an overview of the Mosaic WWW traffic parameters. Choi's traffic model is an on/off-model with alternating phases of packet generation and silence (see Figure 12-3) [Choi99]. An on-phase starts after the arrival and acceptance of a web request. During this phase, the objects of a WWW page are requested. The off-phase represents a silence period after all objects have been retrieved. Thus, the on and off-phases equal the page loading times and page viewing times, respectively. During the on-phase the page's objects are downloaded. We distinguish two types of objects: the main object containing the document's HTML code and inline objects, such as linked objects, images or Java applets. To fetch all those inline objects modern browsers open several TCP connections in parallel after the successful retrieval of the main object. In Table 12-1 the random variables for the object sizes, the number of inline objects and the length of the viewing time are listed. The mean values that are listed below are a little different from those that was used by Choi. We have reduced the mean viewing time as a user of a mobile device usually will spend less time to read a page that one at his home or his office using a desktop PC. We have increased the rest of the values as we guess that future Internet sites, will be heavier than today’s ones.

WWW Parameter

Distribution

Mean

Variance

Viewing time [s]

Weibull

25

8.57.10³

No. of inline objects per page

Gamma

7

130.0

Size of main object [kB]

Log-Normal

13

625.0

Size of inline objects [kB]

Log-Normal

10

1.59.104

Table 12-1: Choi WWW traffic model parameters

Page 57 (80)

WINNER

D1.3 v1.0

Figure 12-3: Choi's Behavioral Model

The amount of data S that is generated during the on-phase is given by

S = s Main +

n Inline

∑S

Inline, i

i= 0

which is a combination of three random variables. The random variable S represents the payload to be transmitted by the HTTP protocol.

12.2

Conversational Voice Model

This model, and its description, is modified from the VoIP model presented in [3]. The underlying traffic models are assumed to apply to all conversational voice applications, regardless of bearer (e.g. IP, circuit switched etc.)

12.2.1 Audio Codecs Voice channels occupy 64 kbit/s using PCM coding when carried over CS links. Compression techniques (Codecs) were developed allowing a reduction in the required bandwidth while preserving voice quality. Within WINNER we consider 3 different rates of conversational voice traffic, corresponding to 8, 32 and 64 kbit/s constant bit rate (during talkspurt), depending on whether we intend the voice to be intelligible to people, intelligible to machines, or pleasant to listen to.

12.2.2 Example Codec (G.723) The G.723 [itu:g_723] is used for speech transmission in videoconferencing systems and is used in the video conference standard H.323 [itu:h_323]. The coder has two possible bit rates: • 5.3 kbit/s • 6.3 kbit/s For the purpose of generating basic traffic models, it is assumed that the characteristics of this codec scale linearly with data rate. It encodes speech or other audio signals in frames using linear predictive analysis by synthesis coding. The excitation signal for the high rate coder is Multi-Pulse Maximum Likelihood Quantization (MPMLQ) and for the low rate coder Algebraic Codebook Excited Linear Predictive (ACELP). The recommendation foresees a frame size of 30 ms in which the speech or other audio signals are encoded. Both rates are a mandatory part of the encoder and decoder. It is possible to switch between the two rates at any 30 ms frame boundary. An option for variable rate operation using discontinuous transmission and noise fill during non-speech intervals is also possible. In addition, there is a look ahead of 7.5 ms which gives a coding delay of 37.5 ms . All additional delays in the implementation and operation of this coder are due to: • actual time spent processing the data in the encoder and decoder • transmission time on the communication link • additional buffering delay for the multiplexing protocol The output of speech coder during periods is depicted in Figure 12-4: Output of Speech Coder G.723 High Rate (6.3 kbit/s) generating speech packets of 24 bytes at high rate and 20 bytes when transmitting at low rate. Silence compression techniques like Voice Activity Detection (VAD) and Comfort Noise Generator (CNG) reduce transmitted data volume during silence intervals of speech. The purpose of the CNG algorithm is to create a noise that matches the actual background noise with a global transmission Page 58 (80)

WINNER

D1.3 v1.0

cost as low as possible. At the transmitting end, the CNG algorithm uses the activity information given by the VAD for each frame, and then computes the encoded parameters needed to synthesize the artificial noise at the receiving end. These encoded parameters compose the Silence Insertion Descriptor (SID) frames, which require fewer bits than the active speech frames and are transmitted during inactive periods.

Figure 12-4: Output of Speech Coder G.723 - High Rate (6.3 kbit/s)

12.2.3 Voice Traffic Characteristics Voice activities can be considered as alternating between two states: talkspurt and silent. Data are generated during talkspurt only, and no data is transmitted during silence, thereby making statistical multiplex gain possible. Paul T. Brady discovered that both talkspurt and silence periods of digitized voice are exponentially distributed [Brady69]. 12.2.3.1 Single Speaker Model The commonly accepted model for a speaker in a voice call is a continuous-time, discrete-state Markov chain. The holding time in each state is assumed to be exponentially distributed with mean 1/? and 1/µ, respectively (see Figure 12-5).

Figure 12-5: Single Speaker Model

The commonly used values are 1/? = 650 ms and 1/µ =352 ms. These values are often referred to as the Traditional Packet Voice Model. Values of 1/? = 742 ms and 1/µ = 435 ms were measured from actual telephone traffic with silence detector of high sensitivity [Yat82]. The fundamental basis of all packet voice performance studies for the past is the classic model of exponential distributions by Brady. This model, however, was based on digitized voice statistics. Its applicability to packet voice with different audio content has not been examined before. Page 59 (80)

WINNER

D1.3 v1.0

Packetization, may change the traffic characteristics of packet voice, since both the techniques and implementations are different. In addition, while digitized voice in the traditional model was mainly concerned with telephone conversations, packet voice will be used for a wider range of new applications that may affect the traffic model too. For instance, a significant amount of applications will be for information or entertainment distribution.

12.2.4 Packet Voice Traffic Model The proposed traffic models for conversational voice (see Table 12-2: Parameters for Voice modelling with Exponential Distribution) are based on the Single Speaker Model as described in 12.2.3.1. During talkspurt periods, the codec generates a CBR every 30ms (based on the high data rate of the G.723, 2.2.2). For low quality voice this CBR is assumed to be 30 byte every 30ms, for medium quality it is 120 byte, and for high quality voice it is 240 byte. Directly after the transition to silent state a 4 byte frame for the CNG is sent. Single -speaker model for digitized speech [Brady69]

Traditional Packet Voice [Deng95]

Packet Voice [Deng95]

Talkspurt

1.34s

0.352s

7.24s

Silence

1.67s

0.65s

5.69s

Table 12-2: Parameters for Voice modelling with Exponential Distribution

The mean call duration for a speech service is 120s. The call duration is negative exponentially distributed.

12.3

Video Streaming

The video streaming traffic model proposed in [3] has been adopted as starting point. One of the characteristic parameters of such model that is very likely to be affected by the evolution of mobile services is the display size and resolution. In this section the traffic model proposed in [3] is extended to cases of increased display size and resolution for various coding format: MPEG1, MPEG2 and MPEG4. The Video Streaming traffic model parameters discussed in [3] all refer to a high resolution of 640 x 480 pixels displays with a frame rate RF = 30 s -1 . For CIF, QCIF and HDTV formats, it is necessary to scale the parameters down or up to other resolutions. CIF (352 x 288) is often applied to laptop video streaming, while QCIF is more suitable for the small display of mobile phones. The frame rates are different for these resolutions, too. For CIF 15 Hz and 30 Hz are common, while for QCIF 10 Hz and 15 Hz are used. HDTV is the standard for High Definition Television. In current practice, HDTV uses 1280 x 720 pixels displays in Progressive Scan Mode (720p) (with a frame rate of 24, 30 or 60 Hz) or 1920 x 1080 pixels displays in Interlace Mode (1080i), but with a reduction of the number of frames per second to 24 Hz. The parameterisation is based on statistics derived from the ``Star Wars'' type of video streaming traffic (see Table 2.12 in [3]). The number of bits per pixel is 24 bit (=3 byte). For VGA, CIF and QCIF formats the traffic model parameters already evaluated in [3] are considered and adopted. For HDTV some approximations are needed to evaluate the parameters of the video sequence. It’s possible to calculate the bit rate Ru of a digitized but uncompressed video sequence through the following formula:

Ru

=

] * RF [ frames ] * [number _ of _ bits ] [ frame] [sec ] [ pixel ] [

x * y pixels

Page 60 (80)

WINNER

D1.3 v1.0

where x*y is the resolution of the video, RF is the frame rate and the last term is the number of bits per pixel. From the above formula the ratio of data rates between two video streaming traffic of the same type for two different display resolutions can be evaluated: such a proportional factor is also approximately the one that exists between I-parameters (mean and standard deviation) applicable to the considered display resolutions. Moreover, the P frames contain less information than I frames, generally they have an average size of about a quarter of the I frames. This compression is achieved by motion compensation. The B frames are the ones with the lowest frame sizes: they have an average size of about half the P frames, and therefore of about an eighth of the I frames. Therefore, the mean P and B frame sizes can be estimated from I mean frame size. Finally, if the mean I frame size of ``Star Wars'' in 640 x 480 resolution is ten times the mean I frame size of a different resolution, the standard deviation of the I frame size has to be reduced by a factor of ten for that different resolution. Applying the above procedure and considerations for all resolutions, all frame types and relative frame rates the results in the following Table 12-3 are obtained. Such table in particular extends the results presented in [3] to HDTV formats.

Page 61 (80)

WINNER

R F [Hz] 60 30 24 15 10

D1.3 v1.0

HDTV (1080i) (1920*1080pixels) I P B µ s µ s µ 832.2 s 330.6 µ s µ s

208.1 134

104 58

HDTV (720p) (1280*720pixels) e I P B 920 230 115 365.4 148 64.5 438 110 55 174 70.7 30.8 0 365 91.3 46 50.7 145 58.7 25.8

e

0 56.1 0 26.7 0 22.3

VGA, NTSC (640*480pixels) I P B

146 58

60 38.6

18.9 10.6

e

CIF (352*288pixels) I P B

e

0 8.9

73.8 29.6

8.1 5.1

2.2 1.2

0 4.5

45.0 18.1

6.8 4.3

3.2 1.8

0 2.7

Table 12-3: Frame sizes of different resolutions [kbit]

Page 62 (80)

QCIF (176*144pixels) I P B

e

6.2 2.5 7.7 3.1

0 0.38 0 0.14

0.8 0.55 0.5 0.3

0.5 0.3 0.15 0.08

WINNER

D1.3 v0.1

It is also possible to calculate the bit rate of a compressed video sequence. To this purpose, a generic GoP (N,M) is considered where N (GOP length) is the I-to-I frame distance and M is the I-to-P frame distance. The specific GoP pattern depends typically on the application type: for example for video broadcast quality applications GoP (15, 3) is used while for video conferencing applications GoP (15,1) is used. The GOP total information size is the sum of the different frame sizes on the basis of the GoP structure. If NI = number of I-frames = 1 NP = number of P-frames NB = number of B-frames then N = NI + NP + NB The total GoP information size is: SG = NI *µI + NP * µP + NB * µB

[Kbit]

where GoP is composed of N = 15 frames in the above cases. The mean frame size

S F is then:

S F = SG / N The refresh rate RF is the frame rate. The average bit rate of the compressed video sequence is finally achieved as multiplication between the average size of the frame

S F and the refresh rate RF :

RC = S F * RF [Mbit/sec] This calculation yields the throughput of a compressed sequence, for MPEG-1 and for a particular resolution and refresh rate. Video Broadcasting: GoP (15,3) This GoP (15,3) pattern is mainly used for broadcast quality applications, as the ideal trade-off between compression efficiency and video quality. The GoP (15,3) pattern is characterized by the following sequence: I B B P B B P B B P B B P B B. Then: SG = µI + 4*µP + 10*µB [Kbit]

S F = SG /15 [Kbit] Here below are the results, in the case of a GoP (15,3) pattern:

RF [Hz] SG [Kbit]

S F [Kbit]

HDTV (1080i) 24 2704.6 180.266

HDTV (720p) 24 1190 79.333

30 1428 95.2

VGA, NTSC 60 30 2990 575 199.333 38.333

CIF

QCIF

15 30 10 104.2 128.2 14.4 7 8.5 0.96

15 11.2 0.75

Page 63 (80)

WINNER

D1.3 v0.1

RC [Mb/sec] 4.326

1.900

2.856 11.96

1.150

0.105 0.255

0.009 0.011

R

Table 12-4: Average bit rate C of the MPEG-1 compressed video sequence “Star Wars” for different resolutions and refresh rates, and with GoP (15,3).

The previous results are applicable to MPEG-1. The average ratio between this coding format and other formats can be considered [28]: § (Bit Rate MPEG-2 – DVD quality) / (Bit Rate MPEG-1 – XVCD quality) ˜ 2.2 in the hypothesis of excellent quality of video. § (Bit Rate MPEG-4 – DIVX quality) / (Bit Rate MPEG-1 – XCVD quality) ˜ 0.4 Moreover, MPEG-4 is primarily designed to handle low bit rate content, from 4800 bit/sec to approximately 4-5Mbit/sec, while MPEG-2 outperforms MPEG-1 at 3Mbit/sec and above, until ˜ 20Mbit/sec. Naturally it would be possible to modify the GoP pattern in order to obtain lower bit rates, but with a lower quality of video. Taking into consideration the above ratios between coding formats, the following table is derived for MPEG-2 from Table 12-4 :

HDTV (1080i) RF [Hz] 24 RC [Mb/sec] 9.517

HDTV (720p) 24 4.180

30 60 6.283 26.312

VGA, NTSC 30 2.530

CIF

QCIF

15 30 0.231 0.561

10 15 0.020 0.024

R

Table 12-5: Average bit rate C of the MPEG-2 compressed video sequence “Star Wars” for different resolutions and refresh rates, and with GoP (15,3).

and the following table is obtained for MPEG-4:

HDTV (1080i) RF [Hz] 24 RC [Mb/sec] 1.730

HDTV (720p) 24 30 60 0.760 1.142 4.784

VGA, NTSC 30 0.460

CIF 15 0.042

QCIF 30 10 0.102 0.0036

15 0.0044

R

Table 12-6: Average bit rate C of the MPEG-4 compressed video sequence “Star Wars” for different resolutions and refresh rates, and with GoP (15,3).

Video Conferencing: GoP (15,1) It is useful to consider also the GoP (15,1), usually used for video conferencing and generally for real time applications with tighter delay parameters, characterized by the following GoP pattern: IPPPPPPPPPPPPPP In this case: SG = µI + 14* µP

S F = SG /15

[Kbit] [Kbit]

and the average bit rate

RC for MPEG-1 is shown in the following table:

HDTV (1080i)

HDTV (720p)

VGA, CIF NTSC

QCIF

Page 64 (80)

WINNER

RF [Hz] SG [Kbit]

S F [Kbit]

D1.3 v0.1

24 24 30 60 30 15 30 3745.6 1643.2 1978 4140 986 140.2 187.2 249.706 109.546 131.866 276.000 65.733 9.346 12.480

RC [Mb/sec] 6

2.630

3.956

16.560

1.972

0.140

0.374

10 15 14.7 17.4 0.980 1.160 0.009 0.017

R

Table 12-7: Average bit rate C of the MPEG-1 compressed video sequence “Star Wars” for different resolutions and refresh rates, and with GoP (15,1).

On the basis of the same approximations used for GoP (15,3), that is: § §

(Bit Rate MPEG-2 – DVD quality) / (Bit Rate MPEG-1 – XVCD quality) ˜ 2.2 (Bit Rate MPEG-4 – DIVX quality) / (Bit Rate MPEG-1 – XCVD quality) ˜ 0.4

it is possible to evaluate the average bit rate for GoP (15,1) for MPEG-2 and MPEG-4 codecs. The following table is derived for MPEG-2:

HDTV (1080i) RF [Hz] 24 RC [Mb/sec] 13.2

HDTV (720p) 24 5.786

30 60 8.703 36.432

VGA, NTSC 30 4.338

CIF

QCIF

15 30 0.308 0.823

10 15 0.020 0.037

R

Table 12-8: Average bit rate C of the MPEG-2 compressed video sequence “Star Wars” for different resolutions and refresh rates, and with GoP (15,1).

and the following table is obtained for MPEG-4:

HDTV (1080i) RF [Hz] 24 RC [Mb/sec] 2.400

HDTV (720p) 24 1.052

30 1.582

60 6.624

VGA, NTSC 30 0.789

CIF

QCIF

15 30 0.056 0.150

10 15 0.004 0.007

R

Table 12-9: Average bit rate C of the MPEG-4 compressed video sequence “Star Wars” for different resolutions and refresh rates, and with GoP (15,1).

12.4

Streaming of audio

This traffic source is characterized at application level by using ON-OFF models. A detailed characterization of these traffic sources can be found in [29]. This is an asymmetric application with few numbers of request packets in the uplink direction. For the downlink: •

Session duration: Fitting the empirical distribution given in [30], Pareto distribution with shape parameter a=1.6 and mean m=40*60=2400s;

•

Session inter-arrival times: exponential distribution with mean

1 3600 = s , where K is the λ 0.16 * k

average number of streaming audio connections performed by a user in a day; •

Session bit rate: the bit rate of an audio flow varies between 64 and 392 kbit/s (scenario element 9) depending on the content and quality of the flow (voice, music, mono, stereo, …). The bit rate have very fast variations due to the content of the sound and compression method (VBR-MP3)

•

Packets are sent on VBR on the session. Jitter up to 2s are allowed and corrected by buffers on the receiver. Packets are sent in UDP, with a length according to [30] of 500bytes.

Page 65 (80)

WINNER

D1.3 v0.1

In [30] empirical measurements with an internet audio streaming server was made, concluding that the server codec follow an ON-OFF scheme, serving several burst of packets (the quantity depends on the data rate) with an OFF period of 1.8 s. But this measurements can not be taking as a general rule because it depends on the codec implementation and other aspects. So for WINNER we can consider a constant flow of UDP packets with variations due to the instantaneous data rate change.

12.5

FTP

The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among hosts, and 4) to transfer data reliably and efficiently. FTP, though usable directly by a user at a terminal, is designed mainly for use by programs. With the above definitions in mind, the following model (shown in Figure 12-6Fehler! Verweisquelle konnte nicht gefunden werden.) may be diagrammed for an FTP service. [7]

Figure 12-6 Model for FTP Use In the figure above, one can see both sides during an FTP session. Following procedures are mainly involved: control connection The communication path between the USER-PI and SERVER-PI for the exchange of commands and replies. This connection follows the Telnet Protocol. data connection A full duplex connection over which data is transferred, in a specified mode and type. The data transferred may be a part of a file, an entire file or a number of files. The path may be between a serverDTP and a user-DTP, or between two server-DTPs. FTP commands A set of commands that comprise the control information flowing from the user-FTP to the server-FTP process. server-FTP process A process or set of processes which perform the function of file transfer in cooperation with a user-FTP process and, possibly, another server. The functions consist of a protocol interpreter (PI) and a data transfer process (DTP). user-FTP process

Page 66 (80)

WINNER

D1.3 v0.1

A set of functions including a protocol interpreter, a data transfer process and a user interface which together perform the function of file transfer in cooperation with one or more server-FTP processes. The user interface allows a local language to be used in the command-reply dialogue with the user. DTP The data transfer process establishes and manages the data connection. The DTP can be passive or active. server-DTP The data transfer process, in its normal "active" state, establishes the data connection with the "listening" data port. It sets up parameters for transfer and storage, and transfers data on command from its PI. The DTP can be placed in a "passive" state to listen for, rather than initiate a connection on the data port. user-DTP The data transfer process "listens" on the data port for a connection from a server-FTP process. If two servers are transferring data between them, the user-DTP is inactive. PI The protocol interpreter. The user and server sides of the protocol have distinct roles implemented in a user-PI and a server-PI. server-PI The server protocol interpreter "listens" on Port L for a connection from a user-PI and establishes a control communication connection. It receives standard FTP commands from the user-PI, sends replies, and governs the server-DTP. user-PI The user protocol interpreter initiates the control connection from its port U to the server-FTP process, initiates FTP commands, and governs the user-DTP if that process is part of the file transfer. In the model described in Figure 12-7, the user-protocol interpreter initiates the control connection. The control connection follows the Telnet protocol. At the initiation of the user, standard FTP commands are generated by the user-PI and transmitted to the server process via the control connection. (The user may establish a direct control connection to the server-FTP, from a TAC terminal for example, and generate standard FTP commands independently, bypassing the user-FTP process.) Standard replies are sent from the server-PI to the user-PI over the control connection in response to the commands. The FTP commands specify the parameters for the data connection (data port, transfer mode, representation type, and structure) and the nature of file system operation (store, retrieve, append, delete, etc.). The user-DTP or its designate should "listen" on the specified data port, and the server initiate the data connection and data transfer in accordance with the specified parameters. It should be noted that the data port need not be in the same host that initiates the FTP commands via the control connection, but the user or the user-FTP process must ensure a "listen" on the specified data port. It ought to also be noted that the data connection may be used for simultaneous sending and receiving. In another situation a user might wish to transfer files between two hosts, neither of which is a local host. The user sets up control connections to the two servers and then arranges for a data connection between them. In this manner, control information is passed to the user-PI but data is transferred between the server data transfer processes. Following is a model of this server-server interaction.

O WUR Q R &

&

RQ WUR O

Figure 12-7: Server-server interaction

Page 67 (80)

WINNER

D1.3 v0.1

The protocol requires that the control connections be open while data transfer is in progress. It is the responsibility of the user to request the closing of the control connections when finished using the FTP service, while it is the server who takes the action. The server may abort data transfer if the control connections are closed without command.

12.6

Telesurgery

First Wireless Surgery [19] NASA is claiming to have carried out the world’s first remote-controlled surgery over a wireless link. The US space agency dropped four astronauts into the Atlantic Ocean in October 2004 to carry out the remote robot-assisted surgical procedure undersea. Although the space agency is purportedly conducting the trials in order to allow remote emergency surgery on the International Space Station, the experiment has far more immediate applications on earth. Wireless robotic surgery could be used for emergencies on ships, submarines and oil-exploration platforms. In future, wireless telesurgery could also be used with mobile operating theatres in remote regions and third-world countries with underdeveloped fixed-line telecommunications infrastructures. Since the NASA experiment used a high-speed point-to-point wireless connection, there would not even need to be a cellular network in place. Telerobotics Assisted Surgery [20] In a country the size of Canada, IP-based technologies have made distance irrelevant while adding convenient and rapid delivery of various essential services between multiple locations. The telerobotics assisted surgery initiative developed at St. Joseph’s Healthcare, a Hamilton, Ontariobased teaching and research hospital, leverages the power of Bell’s networking expertise to provide healthcare services to remote parts of the country and effectively expand the accessibility of critical medical resources. On February 28, 2003, Dr. Mehran Anvari, an internationally renowned specialist in minimal access surgery, performed the world's first hospital-to-hospital telerobotics assisted operation from St. Joseph's to a patient in North Bay General Hospital, Ontario. Using a specially designed robot operating over Bell Canada's national IP backbone, Dr. Anvari assisted Dr. Craig McKinley, a North Bay surgeon, in performing a laparoscopic Nissen fundoplication (acid-reflux) surgery over a distance of approximately 250 miles. Since the success of this first operation, twenty-four additional procedures have been performed using telerobotics. As part of its contribution to the St. Joseph’s telerobotics assisted surgery initiative, Bell Canada is responsible for maintaining the highest level of network performance and reliability necessary for conducting real-time manipulation of a robot from a remote location. Combining the latest advances in laparoscopic surgical techniques, robotics, video compression and IP Internetworking, Bell designed, built and managed all aspects of the service delivery, including the integration of all connectivity software, cabling, end-to-end network management and engineering expertise. Bell conducted extensive testing to ensure that the high levels of stability, reliability and quality of service demanded by a telerobotics assisted surgery application under various network conditions were met. It was Bell’s responsibility to maintain a minimal level of application latency while delivering 8 Mbps of bandwidth that any manipulation of the remote robotic ‘hand’ corresponds with the virtually simultaneous movement of the surgeon’s hand controlling the robot. European Institute of TeleSurgery (EITS) [21] EITS provides surgeon trainees with a new experimental Operating Room dedicated to robotics, a modular and evolutionary structure incorporating a broad range of new technologies. Structurally, the entire OR is composed of metallic partition walls that can be modified, moved and adapted according to technical constraints. The operating table is a modular set (Maquet's) complete with a high-speed cleaning-disinfection system, which optimizes infectious security parameters. Four technical arms encompass the surgical area. On the one hand, they support the whole endoscopic surgical equipment, screens and other dedicated functions, which are available to surgeons.

Page 68 (80)

WINNER

D1.3 v0.1

Thanks to these technical arms, there is no component touching the ground, hence ensuring an optimal hygiene (suspension of the anesthetic arm, videoscopy columns, etc.). All technical arms have access to anesthetic and surgical fluids including compressed air, vacuum and carbon dioxide. On the other hand, they all have video, image, sound, electronic and phone connections to provide screens with great modularity, and display images from any source on any screen (computerized reconstructions and internal/external videoconference images). The OR is entirely remote-controlled via a tactile screen and a voice-controlled system. Therefore, all elements (camera, cold light source, operating table, electrocautery, etc.) can be steered by the surgeon, thereby saving considerable human resources. The robotic system enables surgical teams to train regularly. It also allows continuous monitoring of robotic performances. Eventually, the OR is permanently connected to the broadband ISDN network of the Institute. As a result, videoconferences can be achieved from the surgical theater to the experimental teaching OR. The OR can also be connected to teaching systems, making it possible to spread new technologies and training worldwide. France Telecom – Telesurgery [22][23] France Telecom claims the world's first Trans-Atlantic surgery accomplished using RAD's ATM Device. The challenge was to transfer voice, video and data traffic in real-time for the performance of transAtlantic surgery via robot. The solution was based on a RAD's ACE-2002 ATM multiservice access concentrator, connected over a high speed fiber optic link, reduced delay to 150 milliseconds, making remote-controlled robotic surgery feasible. The benefits of RAD's ACE-2002 are: To provide end-to-end Quality of Service (QoS) through sophisticated policing, monitoring and shaping Reliable systems Compact, low cost solution

Figure 12-8: France Telecom - Telesurgery

ACE-2002 Reduces Delay and Ensures Reliable Transmission of Mission-Critical Data Like Charles Lindbergh's solo trans-Atlantic flight from New York to Paris in 1927, another dramatic, technological breakthrough has linked New York and France, capturing people's imaginations and bringing the world a little closer together. In the first medical operation of its kind, dubbed Operation Lindbergh, doctors in New York performed successful gallbladder surgery – via remote-controlled robotics – on a patient located in Strasbourg, France. In Operation Lindbergh, 7,000 kilometers (4,000 miles) separated the surgical team in New York City and the patient strapped to a hospital gurney in surgical ward A in Strasbourg Civil Hospital in eastern France. The doctor in New York moved the remote control on the console of Computer Motion's Zeus robotic surgical system, which combines robotics, a video display and unique computer software, to manipulate surgical instruments held by a robot in the operating room and perform the minimally invasive surgery. The patient was released from the hospital in 48 hours and resumed normal activity after one week. Real-Time Data, Voice and Video Transmissions The Zeus system relies on broadcast-quality video, IP telephony, videoconferencing and a LAN interconnection. "Previously, the impediment to performing trans-Atlantic operations was the time lag,

Page 69 (80)

WINNER

D1.3 v0.1

which could be as long as one second. That is too long to safely perform a surgical operation," explains Jean-Pierre Temime, Director of Marketing for France Telecom Enterprise Services at France Telecom. Using ATM technology and RAD's ACE-2002 multiservice access concentrator and network termination unit (NTU) over a high speed fiber optic link, France Telecom was able to reduce the transmission delay to 150 milliseconds, a speed that is almost imperceptible to the human eye. This enabled the surgeon in New York to view his progress on a video screen in real time. End-to-End Quality of Service The sophisticated policing, monitoring and shaping capabilities of the ACE-2002 provide end-to-end Quality of Service (QoS), which is crucial for a life -and-death situation such as telesurgery. "This was a very challenging project, since we had to apply our expertise in high speed services within an extremely exacting environment in terms of the reliability and security needed. These are, in fact, the same services we deliver every day to equally demanding corporate customers," says Temime. France Telecom depends on RAD's ACE NTUs in its metropolitan InterLAN HD service and other ATM services.

12.7

Telepresence

Projects [27] There are several research projects in the area of Telepresence, that are described bellow, so that the application requirements for traffic modeling are easier to be derived. TalkingGlove An assistive communication device for non-speaking deaf individuals, which recognizes American Sign Language (ASL) finger-spelling to generate text or synthesized speech. Core to the TalkingGlove system is an instrumented glove and neural-net algorithm for mapping dynamic hand formations into a digital command stream.

CutPlane A solid-modeling interaction metaphor for a standard workstation, displacing the need for orthonormal projections, command line input, and menu command selection, with of continuous 3D access. A CDR spinoff enterprise, Beyond Technologies, developed and implemented the CutPlane interface in conceptual design tool product called 3Form, which further included the concept of 3D tools to represent commands that the operator could select and apply to a 3D object in a particular location, orientation, and manner. RoboGlyph A visual language for controlling and programming robots, RoboGlyph was created to simplify the programming of manipulation tasks for a service robot for quadriplegics. It was designed to take advantage of the presence of the user/programmer and facilitate his or her operation of the robot with graphical representations of the robot's configurations and motions. Also, force-sensing is used to detect and control interactions with the environment, so the user is not responsible for fine-positioning tasks. Experiments with RoboGlyph have shown that, after only one or two hours of training, computer literate health care professionals with no robotics experience can write working robot programs as quickly as expert robot programmers. Expert programmers who use RoboGlyph can program at least as fast as they can with textual robot programming languages, after only one hour of training. The programs written by all RoboGlyph users (sample storyboard) were much easier to read and maintain than similar programs written in textual languages.

VirtualHand

Page 70 (80)

WINNER

D1.3 v0.1 A dynamic simulated, anthropometrically correct, hand model driven by an instrumented glove for computational recreation of the operator's dexterity. The project reached the goal to reconstruct a 3D model of a live human hand for the purpose of visual display or computational dexterous interaction with other 3D models. The interframe data required to dynamically drive the virtual hand was less than 34 bytes, a packet size compatible with standard telephone equipment at 30 Hz, independent of the visual quality of the display.

TeleSign A collaborative design effort between CDR and the Center for the Study of Language and Information, leveraged from the TalkingGlove and VirtualHand projects to develop a system for visual expression and manual communication. The TeleSign system empowers two remote individuals to communicate visible gestures through a shared virtual environment across standard low-bandwidth telephone channels.

Conformal Mapping A new method for achieving interactive deformations of free-form surfaces in the design of geometric shapes. The method requires minimal user input, and allows direct manipulation of any point on the surface. Surface deformations can be highly localized or extend over a large area. Unlike traditional methods providing local control, deformations over an extended area do not require manipulation of a large number of control points. The method allows very concise definition of free-form surfaces with minimal storage requirements, and manipulation of surface patch interiors is, computationally, very inexpensive. Virtual Fixtures as Perceptual Tools for Telepresence Tasks: An application of virtual reality technologies intended to enhance human performance in telepresence tasks by introducing abstract perceptual information into the human- machine interface. This work explores the design and implementation of computer generated entities know as Virtual Fixtures composed of visual, haptic, and auditory sensations. Such fixtures are overlaid on top of the sensory feedback from a remote telepresence worksite and serve as perceptual aids for task performance. This work centers around the development of a design principle known as Design for Perception which provides a basic methodology for efficiently generating and presenting virtual percepts using perceptual rather than physical parameters. VirtualGrasp An extension of the VirtualHand model to enable force closure and contact control of 3D virtual objects for dexterous manipulation.

12.8

Gaming Traffic Characteristics

In order to validate proposed gaming traffic models [12] it has been chosen in [10] to characterize the traffic patterns of “Counter Strike“, a very popular first person shooter based on the Quake engine. In “Counter Strike“ a player partecipate to the game by joining one of two teams. The two teams attack or defend against each other. Player’s “life“ usually is very short and ends within few minutes. “Respawning“, i.e. re-entering the match with a new “life“, is not allowed until the next turn with a turn lasting at most 6 minutes. The games communication model follows the client server approach and uses UDP packets for the exchange of small update information. It has been monitored and registered game traffic over a LAN with 50 total participants for overall 36 hours. More precisely, several matches with 8 to 30 active players have been observed with the matches lasting from 30 to 90 minutes each (6.5 hours gaming in total). The observed game traffic still follows the transmit cycle described in [12]: the server sends game state information to each client where packets are read and processed. Clients synchronize the server game state with their local game state, process player commands and return update packets with the players

Page 71 (80)

WINNER

D1.3 v0.1

movement and status information. Since slower client machines require more processing time for rendering, their packet rate may be lower. Both update and server information packets are usually very small since they only contain movement and status information. Figure 12-9 shows a typical client traffic rate plot with almost constant behaviour. Figure 12-9 a lso shows that traffic from server to clients is more variable, but still rather smooth during a game turn. Between turns server rates may drop to zero for a short time. The observed data rate generated by the server was 16.4 kbit/s to each client and the observed data rate of client generated traffic was 15.7 kbit/s.

Figure 12-9 Example of server and typical client traffic of a 1h session Server Traffic The main characteristic of server traffic besides its slightly varying packet rate is its bursty nature. In each transmit cycle the server generates a burst of packets - one packet for every active client. Consequently, the total data rate depends on the number of active clients. Thus, it makes sense to evaluate the server traffic per client instead of its summary traffic. This also allows to identify client specific variations. Figure 12-9 shows that server traffic may stop for a short time. These stops mark pauses in the match which are due to changing a scenario or options. The purpose is not to describe those pauses but only consider busy periods. This means that it has been only considered inter-arrival times less than 1 second in the following evaluations. Client Traffic Client traffic is characterized by an almost constant packet and data rate as shown in Figure 12-9 above. Again it has been evaluated the captured data for each client separately. In order to remove traffic patterns resulting from player pauses or waiting time between matches or turns it has been only considered packet inter-arrival times smaller than 1 second. It has been seen that the packet inter-arrival time shows clear peaks for the clients but also that the client behaviour differs, although only within a limited range. This difference is caused by different client hardware performance and settings as Borella has shown. An evaluation of all client packets results in a mean inter-arrival time of 41.7 ms and a coefficient of variation of 0.24. The long tailed behaviour of the distribution function is caused by very few large interarrival times at around 600 to 800 ms. The packet sizes of the clients vary around a mean of 82 Bytes with a coefficient of variation of 0.12. It has been seen that the probability density functions look similar for each client. They show a peak around 80 Bytes. The long tail shape of the distribution function is caused by few packets with around 200 and around 300 Bytes. The function shows that 99% of all packets range between 60 and 110 Bytes.

13.

Annex – TCP/IP

13.1

TCP/IP Definition

Short for Transmission Control Protocol/Internet Protocol, the suite of communication protocols used to connect hosts on the Internet. TCP/IP uses several protocols, the two main ones being TCP and IP. TCP/IP is built into the UNIX operating system and is used by the Internet, making it the de facto standard for transmitting data over networks. Even network operating systems that have their own protocols, such as Netware, also support TCP/IP. While there is no universal agreement about how to describe TCP/IP with a layered model, it is generally viewed as being composed of fewer layers than the

Page 72 (80)

WINNER

D1.3 v0.1

seven used in the OSI model. Most descriptions of TCP/IP define three to five functional levels in the protocol architecture. The four-level model illustrated in Fig.1 is based on the three layers (Application, Host-to-Host, and Network Access) with the addition of a separate Internet layer. This model provides a reasonable pictorial representation of the layers in the TCP/IP protocol hierarchy. The four-layered structure of TCP/IP is seen in the way data is handled as it passes down the protocol stack from the Application Layer to the underlying physical network. Each layer in the stack adds control information to ensure proper delivery. This control information is called a header because it is placed in front of the data to be transmitted. Each layer treats all of the information it receives from the layer above as data and places its own header in front of that information. The addition of delivery information at every layer is called encapsulation. (Fig.2) When data is received, the opposite happens. Each layer strips off its header before passing the data on to the layer above. As information flows back up the stack, information received from a lower layer is interpreted as both a header and data. Each layer has its own independent data structures. Conceptually, a layer is unaware of the data structures used by the layers above and below it. In reality, the data structures of a layer are designed to be compatible with the structures used by the surrounding layers for the sake of more efficient data transmission. Still, each layer has its own data structure and its own terminology to describe that structure. Fig.3 shows the terms used by different layers of TCP/IP to refer to the data being transmitted. Applications using TCP refer to data as a stream. TCP calls data a segment. The Internet layer views all data as blocks called datagrams. TCP/IP uses many different types of underlying networks, each of which may have a different terminology for the data it transmits. Most networks refer to transmitted data as packets or frames.

Fig.2

13.2

Fig.3

Transport layer:

The protocol layer just above the Internet Layer is the Host-to-Host Transport Layer. This name is usually shortened to Transport Layer. The two most important protocols in the Transport Layer are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). TCP provides reliable data delivery service with end-to-end error detection and correction. UDP provides low-overhead, connectionless datagram delivery service. Both protocols deliver data between the Application Layer and the Internet Layer. Applications programmers can choose whichever service is more appropriate for their specific applications.

13.3

TCP

TCP is described by RFC 793 - Transmission Control Protocol. Its status is recommended, but in practice every TCP/IP implementation that is not used exclusively for routing will include TCP. TCP provides considerably more facilities for applications than UDP, notably error recovery, flow control and reliability. TCP is a connection-oriented protocol unlike UDP which is connectionless. Most of the user

Page 73 (80)

WINNER

D1.3 v0.1

application protocols, such as Telnet and FTP, use TCP. The two processes communicate with each other over a TCP connection (InterProcess Communication - IPC), as shown in Fig.4. Process 1

…

Port m TCP

IP

Process 2

…

Reliable TCP Connection

…

Unreliable IP Datagram

Host A

Port n

…

TCP

IP

Host B Fig.4 TCP - Connection between Processes.

•

TCP CONCEPT: As noted above, the primary purpose of TCP is to provide reliable logical circuit or connection service between pairs of processes. It does not assume reliability from the lower-level protocols (such as IP), so TCP must guarantee this itself. TCP can be characterized by the following facilities it provides for the applications using it: Stream Data Transfer From the application's viewpoint, TCP transfers a contiguous stream of bytes through the network. The application does not have to bother with chopping the data into basic blocks or datagrams. TCP does this by grouping the bytes in TCP segments, which are passed to IP for transmission to the destination. Also, TCP itself decides how to segment the data and it can forward the data at its own convenience. Sometimes, an application needs to be sure that all the data passed to TCP has actually been transmitted to the destination. For that reason, a push function is defined. It will push all remaining TCP segments still in storage to the destination host. The normal close connection function also pushes the data to the destination. Reliability TCP assigns a sequence number to each byte transmitted and expects a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a timeout interval, the data is retransmitted. Since the data is transmitted in blocks (TCP segments) only the sequence number of the first data byte in the segment is sent to the destination host. The receiving TCP uses the sequence numbers to rearrange the segments when they arrive out of order, and to eliminate duplicate segments. Flow Control The receiving TCP, when sending an ACK back to the sender, also indicates to the sender the number of bytes it can receive beyond the last received TCP segment, without causing overrun and overflow in its internal buffers. This is sent in the ACK in the form of the highest sequence number it can receive without problems. This mechanism is also referred to as a windowmechanism and we discuss it in more detail later in this chapter. Multiplexing Is achieved through the use of ports, just as with UDP. Logical Connections The reliability and flow control mechanisms described above require that TCP initializes and maintains certain status information for each data stream. The combination of this status, including sockets, sequence numbers and window sizes, is called a logical connection. Each connection is uniquely identified by the pair of sockets used by the sending and receiving processes. Full Duplex TCP provides for concurrent data streams in both directions.

Page 74 (80)

WINNER

D1.3 v0.1

• TCP SEGMENT FORMAT The TCP Segment header is a minimum of 20 bytes long. The TCP segment format is shown in Fig.5. Source Port

Destination Port Sequence Number Acknowledgment Number

Data Offset

Reset

U R G

A C K

P S H

R S T

S Y N

F I N

Checksum

Window

Urgent Pointer

Option

Padding

Data Bytes Fig.5 TCP header

Where: Source Port The 16-bit source port number, used by the receiver to reply. Destination Port The 16-bit destination port number. Sequence Number The sequence number of the first data byte in this segment. If the SYN control bit is set, the sequence number is the initial sequence number (n) and the first data byte is n+1. Acknowledgment Number If the ACK control bit is set, this field contains the value of the next sequence number that the receiver is expecting to receive. Data Offset The number of 32-bit words in the TCP header. It indicates where the data begins. Reserved Six bits reserved for future use; must be zero. URG Indicates that the urgent pointer field is significant in this segment. ACK Indicates that the acknowledgment field is significant in this segment. PSH Push function. RST Resets the connection. SYN Synchronizes the sequence numbers. FIN No more data from sender. Window Used in ACK segments. It specifies the number of data bytes beginning with the one indicated in the acknowledgment number field which the receiver (= the sender of this segment) is willing to accept. Checksum The 16-bit one's complement of the one's complement sum of all 16-bit words in a pseudo-header, the TCP header and the TCP data. While computing the checksum, the checksum field itself is considered zero. Urgent Pointer Points to the first data octet following the urgent data. Only significant when the URG control bit is set. Options Just as in the case of IP datagram options, there are currently seven options defined: Table 1. TCP - IP Datagram Options Kind Length Meaning 0 End Of Option List 1 No-Operation 2 4 Max Segment Size 3 3 Window Scale 4 2 Sack Permitted 5 X Sack 8 10 Time Stamp

Padding All zero bytes used to fill up the TCP header to a total length that is a multiple of 32 bits. •

MAX DIMENSION SEGMENT OPTION: Not all the segments sent through a connection will have the same dimension, however both the TX and RX sides have to negotiate the

Page 75 (80)

WINNER

D1.3 v0.1

maximum segment that they will transfer. The TCP software uses the field OPTIONS to negotiate with the TCP software on the other side of the connection; an option allows to specify the MSS (Maximu m Segment Size) that will be received/transmitted. For the computers connected to high speed local area networks it is important, above all, to choose a maximum dimension of the segments that transport the data packets to make good use of the bandwidth. If the two communication terminals are on the same physical network, TCP calculates therefore such a maximum segments dimension so that the resultant IP datagrams correspond to the MTU of network. If the end points are not on the same physical network, TCP tries to discover the minimum MTU size along the path between the terminals or choose a maximum dimension of the segments of 536 bytes (the default dimension of an IP datagram, that is 576 byte, decreased of the standard dimension of the IP and TCP headings). In general, to choose a correct value for the maximum dimension of the segments can be difficult, because the performances can be low for extremely great or extremely small dimensions. When the dimension of the segments is reduced, the use of the network is someway limited. TCP segments travel encapsulated in IP datagram that in turn are encapsulated in frame of physical networks; therefore every segment has at least 40 byte of TCP and IP heading besides the data. The datagrams that bring only one byte of data use at most 1/41 of the bandwidth of the underlying network for the user data. On the other hand, also extremely great dimensions of the segments can cause low performances, since this means extended IP datagram. When these datagrams travel through a network with a small MTU, IP has to fragment them. Differently from a TCP segment, the receipt of an IP fragment cannot be confirmed and the fragment cannot be independently transmitted: all the fragments that compose a datagram need to arrive correctly or the whole datagram needs to be retransmitted. Since probability to loose a fragment is not zero, increasing the dimension of the segments above the fragmentation threshold decreases the possibility that the datagram arrives correctly or, equivalently, the transfer rate. In theory, the optimum dimension of the segments, S, is obtained when the IP datagrams that transport them are the greatest possible without the need to resort to the fragmentation in any point along the path from source to destination. In practice, to find S is difficult for a lot of reasons. Firstly, the greatest part of the TCP implementations do not include a mechanism to perform what described above. Secondly, since the routers over inter-net can change the paths dynamically, the route that the datagrams follow between a couple of computer can change dynamically, and the same applies for the dimension in which the datagrams must have fragmented. Finally, the perfect dimension depends on the headings of the protocol of lower level (the dimension of the segments may need, for instance, to be reduced in order to accomodate the IP options). The optimal dimension of the segments is still object of research.

13.4

IPver4

The current IP specification can be found in RFCs 791, 950, 919 and 922, with updates in RFC 1349. IP is the protocol that hides the underlying physical network by creating a virtual network view. It is an unreliable, best-effort and connectionless packet delivery protocol. Note that best-effort means that the packets sent by IP may be lost, out of order, or even duplicated, but IP will not handle these situations. It is up to the higher layer protocols to deal with these situations. One of the reasons for using a connectionless network protocol was to minimize the dependency on specific computing centers that used hierarchical connection-oriented networks. The DoD intended to deploy a network that would still be operational if parts of the country were destroyed. During earthquakes, this has been proved to be true for the Internet. • IP ADDRESSING: IP addresses are represented by a 32-bit unsigned binary value which is usually expressed in a dotted decimal format. The mapping between the IP address and an easier-to-read symbolic name is done by the Domain Name System discussed (DNS). • IP DATAGRAM: The unit of transfer of a data packet in TCP/IP is called an IP datagram. It is made up of a header containing information for IP and data that is only relevant to the higher level protocols.

Page 76 (80)

WINNER

D1.3 v0.1

IP can handle fragmentation and re-assembly of IP datagrams. The maximum length of an IP

Header

Physical Network Header

•

Data

Base IP Datagram

Encapsulated within the physical network's frame

IP Datagram as Data

datagram is 65,535 bytes (or octets). There is also a requirement for all TCP/IP hosts to support IP datagrams of size up to 576 bytes without fragmentation. Fragments of a datagram all have a header, basically copied from the original datagram, and data following it. They are treated as normal IP datagrams while being transported to their destination. Note, however, that if one of the fragments gets lost, the complete datagram is considered lost since IP does not provide any acknowledgment mechanism, so the remaining fragments will simply be discarded by the destination host. IP DATAGRAM FORMAT: The IP datagram header is a minimum of 20 bytes long: VERS

HLENG

Service Type ID

TTL

Total Lenght FLG

Protocol

Fragment Offset Header Checksum

Source IP Address Destination IP Address IP Option

Padding Data … Fig.6 IP Header

Where: VERS The version of the IP protocol. The current version is 4. 5 is experimental and 6 is IPv6. HLEN The length of the IP header counted in 32-bit quantities. This does not include the data field. Service Type The service type is an indication of the quality of service requested for this IP datagram. Total Length The total length of the datagram, header and data, specified in bytes. Identification A unique number assigned by the sender to aid in reassembling a fragmented datagram. Fragments of a datagram will have the same identification number. Flags Various control flags. Fragment Offset Used with fragmented datagrams, to aid in reassembly of the full datagram. The value is the number of 64-bit pieces (header bytes are not counted) that are contained in earlier fragments. In the first (or only) fragment, this value is always zero. Time to Live Specifies the time (in seconds) this datagram is allowed to travel. Each router where this datagram passes is supposed to subtract from this field its processing time for this datagram. Actually a router is able to process a datagram in less than 1 second; thus it will subtract one from this field, and the TTL becomes a hop-count metric rather than a time metric. When the value reaches zero, it is assumed that this datagram has been travelling in a closed

Page 77 (80)

WINNER

•

D1.3 v0.1

loop and it is discarded. The initial value should be set by the higher level protocol that creates the datagram. Protocol Number Indicates the higher level protocol to which IP should deliver the data in this datagram. Header Checksum Is a checksum on the header only. It does not include the data. The checksum is calculated as the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. For the purpose of this calculation, the checksum field is assumed to be zero. If the header checksum does not match the contents, the datagram is discarded because at least one bit in the header is corrupt, and the datagram may even have arrived at the wrong destination. Source IP Address The 32-bit IP address of the host sending this datagram. Destination IP Address The 32-bit IP address of the destination host for this datagram. Options Variable length. An IP implementation is not required to be capable of generating options in the datagrams it creates, but all IP implementations are required to be able to process datagrams containing options. The Options field is variable in length. There may be zero or more options. Padding If an option is used, the datagram is padded with all-zero bytes up to the next 32-bit boundary. Data The data contained in the datagram is passed to a higher level protocol, as specified in the protocol field. FRAGMENTATION: When an IP datagram travels from one host to another it can cross different physical networks. Physical networks have a maximum frame size, called the maximum transmission unit (MTU), that limits the length of a datagram that can be placed in a physical frame. Therefore, a scheme has been put in place to fragment long IP datagrams into smaller ones, and to reassemble them at the destination host. IP requires that each link has an MTU of at least 68 bytes, so if any network provides a lower value than this, fragmentation and re-assembly must be implemented in the network interface layer in a way that is transparent to IP. 68 is the sum of the maximum IP header length of 60 bytes and the minimum possible length of data in a non-final fragment (8 bytes). IP implementations are not required to handle unfragmented datagrams larger than 576 bytes, but most implementations will handle larger values, typically slightly more than 8192 bytes or higher, and rarely less than 1500. An unfragmented datagram has all-zero fragmentation information. That is, the more fragments flag bit is zero and the fragment offset is zero. When fragmentation is to be done, the following steps are performed: o The DF flag bit is checked to see if fragmentation is allowed. If the bit is set, the datagram will be discarded and an error will be returned to the originator using ICMP. o Based on the MTU value, the data field is split into two or more parts. All newly created data portions must have a length that is a multiple of 8 bytes, with the exception of the last data portion. o All data portions are placed in IP datagrams. The header of these datagrams are copies of the original one, with some modifications: – The more fragments flag bit is set in all fragments except the last. – The fragment offset field in each is set to the location this data portion occupied in the original datagram, relative to the beginning of the original unfragmented datagram. The offset is measured in 8-byte units. – If options were included in the original datagram, the high order bit of the option type byte determines whether or not they will be copied to all fragment datagrams or just to the first one. For instance, source route options have to be copied in all fragments and therefore they have this bit set. – The header length field of the new datagram is set. – The total length field of the new datagram is set. – The header checksum field is re-calculated. o Each of these fragmented datagrams is now forwarded as a normal IP datagram. IP handles each fragment independently, that is, the fragments can traverse different routers to the intended destination, and can be subject to further fragmentation if they pass through networks that have smaller MTUs. At the destination host, the data has to be reassembled into one datagram. The identification field of the datagram was set by the sending host to a unique number (for the source host, within the limits imposed by the use of a 16-bit number). As fragmentation doesn't alter this field, incoming fragments at the receiving side can be identified if this ID field is used together with the source and destination IP addresses in the datagram. In order to reassemble the fragments, the receiving host allocates a buffer in storage as soon as the first fragment arrives. A timer routine is then

Page 78 (80)

WINNER

•

13.5

D1.3 v0.1

started. When the timer times out and not all of the fragments have been received, the datagram is discarded. The initial value of this timer is called the IP datagram time-to-live (TTL) value. It is implementation-dependent, and some implementations allow it to be configured. When subsequent fragments of the datagram arrive before the timer expires, the data is simply copied into the buffer storage at the location indicated by the fragment offset field. As soon as all fragments have arrived the complete original unfragmented datagram is restored, and processing continues just as for unfragmented datagrams. MTU SIZE AND FRAGMENTATION: Ideally, the whole IP datagram perfectly adapts to a physical frame making the transmission efficient through the physical network. To get such result, the IP planners could select the dimension of the datagram so that this always perfectly adapts to a frame. But it is not easy to define the correct dimension. Infact a datagram can travel on many types of physical networks while it is moving through an inter-net to reach its final destination. To understand the problem it is necessary to refer to the an hardware related aspect of the networks: every packet switched communication technology sets a fixed superior limit on the quantity of data that can be transferred in a physical frame (e.g.: 1500 byte of data for Ethernet, 4470 byte of data for frame for FDDI, etc.). These limits are defined network MTU (Maximum Transfer Unit). The approach of limiting the datagrams to the smallest possible MTU in the inter-net makes the transfers inefficient when the datagrams pass through networks that can transport frames of greater dimensions. On the other hand, to allow the datagrams to be greater than the minimum MTU means that they cannot always adapt to a single frame. The purpose of inter-net is to hide the underlying network technologies and to make the communication comfortable for the user. Instead of planning some datagrams that respect the limitation of the minimal MTU size of the physical nets the TCP/IP software chooses an initial appropriate datagram dimension and finds the way to reduce great datagram in sma ller parts when they have to cross a network with a small MTU. This division process is known as fragmentation and the various resulting parts are said fragments. The fragmentation usually happens on a router in any point of the path between the source of the datagram and its final destination. The router receives a datagram from a network with a great MTU and has to send it to a network whose MTU is smaller than the datagram. The dimension of the fragments is select so that each one can be sent through the underlying network in a single frame. At the destination the fragments have to be assembled to create a complete copy of the original datagram. The IP protocol doesn't limit the dimension of the datagrams neither it guarantees that those of greater dimensions come be envoyed without fragmentation. The sender can choose any dimension it is felt appropriate; the fragmentation and the assembling operations happen automatically, without that the source has to perform any particular operations. The IP specifications say that the routers have to transmit without fragmentation the datagrams of dimensions up to the superior limit of the MTU sizes of the networks to which they are connected. Besides, a router has always to manage the datagrams up to 576 byte (also the hosts are required to accept and assemble, if necessary, the datagrams of at least 576 byte). Every fragment contains a heading of the datagram that reproduces the great part of the original heading (except the bit in the field FLAGS that points out that it is a fragment), followed by as many data as it can be transported in the fragment, maintaining anyway a total length inferior to that of the MTU of the network on which it has to travel.

IPver6

IPv6 offers the following significant features: • A dramatically larger address space, said to be sufficient for the next 30 years • Globally unique and hierarchical addressing, based on prefixes rather than address classes, to keep routing tables small and backbone routing efficient • A mechanism for the auto configuration of network interfaces • Support for encapsulation of itself and other protocols • Class of service to distinguish types of data • Improved multicast routing support (in preference to broadcasting) • Built-in authentication and encryption • Transition methods to migrate from IPv4 • Compatibility methods to coexist and communicate with IPv4 o

IPver6 HEADER: IPv6 uses the term packet rather than datagram. The meaning is the same, although the formats are different. IPv6 uses the term node for any system running IPv6, that is, a host or a router. An IPv6 host is a node that does not forward IPv6 packets that are not explicitly

Page 79 (80)

WINNER

o

D1.3 v0.1

addressed to it. A router is a node that does forward IP packets not addressed to it. The format of the IPv6 packet header has been simp lified from its counterpart in IPv4. The length of the IPv6 header is increased to 40 bytes (from 20 bytes), and contains two 16-byte addresses (source and destination) preceded by 8 bytes of control information. The IPv4 header has two 4-byte addresses preceded by 12 bytes of control information and possibly followed by option data. The reduction of the control information and the elimination of options in the header for most IP packets are intended to optimize the processing time per packet in a router. The infrequently used fields that have been removed from the header are moved to optional extension headers when they are required. PACKET SIZE: All IPv6 nodes are expected to dynamically determine the maximum transmission unit (MTU) supported by all links along a path (as described in RFC 1191 — Path MTU Discovery) and source nodes will only send packets that do not exceed the Path MTU. IPv6 routers will therefore not have to fragment packets in the middle of multihop routes and allow much more efficient use of paths that traverse diverse physical transmission media. IPv6 requires that every link supports an MTU of 576 bytes or greater.

13.6

Mobile IP

In general, the terms mobile and mobile consumer computing refer to a system that can move from a position to another. Mobility is often associated to wireless technologies that allow high speed movement on long distances. The speed of movement by itself doesn't represent for IP a problematic aspect; difficulties arise rather when a host passes from a network to another. For instance, a portable PC connected to a W-LAN can move quickly without problems within the coverage range of the transmitter without effects on IP; to disconnect a desk computer and to connect it to a different network requires, instead, a reconfiguration of the protocol, since the IP addressing scheme is planned and optimized for a fixed environment. Since the IP address of an host includes a network prefix, moving the host in a new network means that: • the address of the host has to change • the routers have to establish a new path to reach the host through the whole network. None of the two alternatives is valid. On one hand, changing an address demands time, that the mobile terminal and interrupts all the connections of the existing transport layer. Besides, if the host contacts a server that uses the address to authenticate the clients, a further change to the DNS may be necessary. On the other hand, managing specific routings toward every host is an unsuitable technique to systems of great dimensions, because it needs a space in the routing charts proportional to the number of host and consequently such path transmission consumes a lot of bandwidth. The greatest challenge for the mobility is to allow a host to preserve its address without requiring that the routers know of a specific routing path towards it. Mobile IP resolves the problem allowing a single mobile terminal to contemporarily hold two addresses: the first one, that can be thought as the principal address of the mobile terminal, is permanent and fixed and is the address that the applications and the transport protocols use; the second one, that can be considered as a secondary address, is temporary, it changes when the mobile terminal moves and is valid only while the mo bile terminal visits a certain position. A mobile host gets a principal address from its origin network of affiliation (home). Once it moves to an external network and receives a secondary address, the mobile terminal has to send the secondary address to an agent (usually a router) in the home network. The agent handles to intercept the datagrams sent to the principal address of the mobile terminal and uses IP encapsulation within IP to forward through tunnel every datagram to the secondary address. If the mobile terminal is moved again, it gets a new secondary address and informs the fixed agent of its new position; when it returns in the home network, it has to contact the agent to cancel the recording, which means that the agent will stop to intercept the datagrams. Equally, a mobile terminal can choose to cancel the recording in any moment (for instance, when it leaves a remote position). Mobile IP is conceived for general mobility but not for high speed mobility because of the delay caused by the regis tration procedure. In particular, after the mobile terminal has been moved, a mobile terminal has to realize that it has changed position, to communicate with the external network to get a secondary address and then to communicate through the inter-net with its agent in the home network in order to organize the data forwarding.

Page 80 (80)