The Composite Radio Environment Conceptappropriate radio segment (short-term optimisation). •...
Transcript of The Composite Radio Environment Conceptappropriate radio segment (short-term optimisation). •...
1
THE COMPOSITE RADIO ENVIRONMENT
CONCEPT∆ρ. ΧΑΡΑΛΑΜΠΟΣ ΣΚΙΑΝΗΣ
ΙΝΣΤΙΤΟΥΤΟ ΠΛΗΛΟΡΟΡΙΚΗΣ & ΤΗΛΕΠΙΚΟΙΝΩΝΙΩΝΕΚΕΦΕ ‘∆ΗΜΟΚΡΙΤΟΣ’
Μεταπτυχιακό Πρόγραµµα Σπουδών «Έλεγχος και ∆ιαχείριση ∆ικτύων»
Τµήµα Μηχανικών Πληροφοριακών & Επικοινωνιακών ΣυστηµάτωνΣχολή Θετικών Επιστηµών
Πανεπιστήµιο Αιγαίου
ΣΑΜΟΣ 7-8/04/2003
2
The Composite Radio Environment Concept
• A composite radio platform is comprised of heterogeneous wireless access components, such as WLAN, GPRS, UMTS, HIPERLAN, DVB-T, offering wideband wireless access to broadband-IP based services, and ‘co-operating’ with each other.
• A terminal as part of such a platform supports at least one wireless access technology. To take full advantage of such a composite environment the terminal should be able to perform vertical handover among the various heterogeneous wireless segments. An enhancement to this could be a terminal using traffic and environment conditions for selecting the appropriate radio segment (short-term optimisation).
• Mid-term network-level composite radio resources optimisation could be achieved via the efficient joint utilisation of resources of heterogeneous radio segments through a suitable centralised composite radio management system.
2
3
Core Composite Radio Environment Components
PC
MC
IA
56K
INSERT THIS END
PC
MC
IA
56K
INSERT THIS END
4
Core Composite Radio Environment Components
• A composite radio infrastructure comprising commercial GPRS segments, a WLAN testbed that is compatible to the IEEE802.11b standard, a DVB-T testbed, and an interconnecting IP backbone.
• Multimode terminals, capable of operating in the composite radio environment and comprising functionality (provided through a Terminal Station Management System -TSMS) for conducting (or participating in) decisions regarding the most appropriate radio technologies, through which IP-based services can be obtained efficiently, in terms of cost andQoS.
• A Network and Service Management System - NSMS for the control and management of the composite radio infrastructure. This system will enable the joint optimisation of the alternate radio network segments, so as to deliver services efficiently, in terms of cost and QoS.
• Web-based applications, services and multimedia content.
3
5
Functional and Architectural Framework
PolicyRepositoryDatabase
User sDatabase
DVB
WLAN
GPRS
Sessions &Communication
Manager
NetworkManager
ServiceManager
ServiceDatabase
Monitor
QoS
Req
uire
mne
nts
Serv
ice
clas
s d
efin
ition
s
RA
TD
ecis
ion
ServiceManager
QoSRequiremnentsService class definitions
NSMS area
MS area
NetworkManager
NSMS /TSMS
Measurement & Decisions
CommunicationManager
Logical ManagementRegistration /
Authentication"Generic Event
Specifier"Session Description
QoS
Req
uire
mne
nts
Serv
ice
clas
sde
finiti
ons
TSMS area
App
licat
ion
Inte
rfac
e
Adapters
PC
MC
IA
56K
INSERT THIS END
Video RequestCREDO Application
Other NSMSCommunication path
6
Functional and Architectural FrameworkNSMS modules description
• Session & Communication Manager:– Performs all operations concerning communication with TSMS and
other NSMS entities. – Contains a local or a distributed database containing users profile data
(authentication data, service contract etc).• Network Manager:
– The main module of NSMS. – Communicates with Session & Communication Manager module to
receive/send data towards TSMS and – Interacts with Service Manager to retrieve all data needed for
services profile and QoS levels.• Service Manager:
– Retrieve service profiles from a database. – Collaborates with Network Manager in order to provide all necessary
data about application profiles.
4
7
Functional and Architectural FrameworkTSMS modules description
• Session & Communication Manager:– Implements the communication with other composite radio environment
components. – For the communication between TSMS and composite radio environment
tailor-made applications there is a different module (i.e., Application Interface module).
– The combination of these two modules performs the authorization request towards NSMS.
• Network Manager:– Similar to NSMS module, – Monitor network parameters as they are provided by network adapters
(attached in the MS), – handle all configuration issues (i.e. IP assignment) and – select/re-select network interface.
• Service Manager:– Responsible to contact NSMS or a service profile database to retrieve all
the necessary info
8
Network and Service Management System (NSMS)
5
9
Presentation Overview
• General NSMS structure – System overview– Session manager
• Role• Functionality
– Network managers (GPRS, WLAN, DVB-T)• General Role• Components
– Role– Functionality
10
NSMS Full Component Overview
RBMS (G)
GPRS NSMSarea
MSPM (G) RMS - RATDP (G)
RMS - RATIP (G)
VE
Service Requester ServiceManagerService
Database
User sDatabase
Session Manager
Service Analyzer
NSMS Comm Manager
Session &Communication Manager
NetworkManagerPolicy
RepositoryDatabase
GPRS
RBMS (W)
WLAN NSMSarea
MSPM (W) RMS - RATDP (W)
RMS - RATIP (W)
VE
Service Requester ServiceManagerService
Database
User sDatabase
Session Manager
Service Analyzer
NSMS Comm Manager
Session &Communication Manager
NetworkManagerPolicy
RepositoryDatabase
WLAN
RBMS (D)
DVB NSMSarea
MSPM (D) RMS - RATDP (D)
RMS - RATIP (D)
VE
Service Requester ServiceManagerService
Database
User sDatabase
Session Manager
Service Analyzer
NSMS Comm Manager
Session &Communication Manager
NetworkManagerPolicy
RepositoryDatabase
DVB
6
11
NSMS Full Component OverviewNetwork Manager modules (1)
• Managed System Performance Monitoring (MSPM):– Capture the (changing with time) conditions that originate from the environment
(service area) of the managed GPRS, WLAN, and DVB infrastructure.• Resource Brokerage and Service Management (RBSM):
– Brokerage between the network resources and the service providers (SPs), so as to enable the latter to request the reservation of resources (establishment of virtual networks) over the managed network infrastructure.
• Resource Management Strategies (RMS):– Dynamically find and impose the appropriate GPRS, WLAN, and DVB network
infrastructure reconfigurations, through which the service provider requests, and/or the (new) service area conditions, will be handled in the most cost-efficient manner. RMS is partitioned into two parts,
– RMS-RATIP (RMS - Radio Access Technology Independent Part) - independent to the Radio Access Technology that the NSMS belongs to - and
– RMS-RATDP (RMS - Radio Access Technology Dependent Part) - dependent to the Radio Access Technology that the NSMS belongs to.
12
NSMS Full Component OverviewNetwork Manager modules (2)
• Validation Engine (VE):– Enables off-line testing and validation of the management decisions.
• NSMS Communication Manager:– Provide a communication interface with other NSMS entities, used by RBMS in
order to provide a distribute optimization algorithm for the allocation of MS in the three network segments.
• Session Manager:– Provide a communication interface between TSMS entities and NSMS.
• Service Analyzer & Service Requester:– Components that format TSMS requests for services (as they arrive through
Session Manager), with the help of Service DB, into proper requests for RBMS.
7
13
System Overview – NSMS Structure
TSMS Managed Networks(GPRS, WLAN, DVB-T)
NSMS Structure
Session Manager
Network Manager
RMS-RATDPRMS-RATDP
MonitoringMonitoring
RMS-RATIPRMS-RATIPResource Brokerage Service Management
(RBSM)
Resource Brokerage Service Management
(RBSM)
Resource Management Strategies
Technology Independent
Technology Dependent
14
Software Architecture
IP Backbone Network
GPRS
Session Manager
Network Manager W
LAN
Session Manager
Network Manager D
VB-T
Session Manager
Network Manager
Service Area Region
8
15
Session Manager Role
• Exploits the interface with the TSMS
• Issues recommendations to the TSMS– Best network, QoS level
per application– Look up operations– Types of “light”
optimisation problems• Receives requests and
reports
TSMS Managed Networks(GPRS, WLAN, DVB-T)
NSMS Structure
Session Manager
Network Manager
RMS-RATDPRMS-RATDP
MonitoringMonitoring
RMS-RATIPRMS-RATIPResource Brokerage Service Management
(RBSM)
Resource Brokerage Service Management
(RBSM)
16
Session Manager FunctionalityCommunication with TSMS (CTNP)
• Service Contract Information Request issued by the TSMS• Service Contract Information Reply issued by the Session
Manager– Service Contract Information Reply = (Service Definition 1,…,
Service Definition N)• Service Definition
– Service Identifier– Service QoS parameters– Cost Related Parameters– Candidate network list
• Service Request issued by the TSMS– Application– Quality of Service Levels– Cost related information– Network availability
• Service Reply issued by the Session Manager– indicates the appropriate radio technology
• Quality Report Request issued by Session Manager• Quality Report Reply issued by TSMS
– measurements reflecting the quality level at which each service is provided to the particular terminal
• Handover Notification
Service Configuration
Service Request
Session ManagerSession
ManagerTSMSTSMS
Assignment of applications to quality levels and network(s)
Quality Report Reply
Quality Report Request
Session ManagerSession
Manager
Formulation of Quality Report containing
measurements reflecting the perceived
quality levels.
TSMSTSMS
9
17
Status and policies of underlying networks
OptimisationProcess
Allocation of applications to network
Allocation ofapplications to quality levels
Session-level optimisation
User class profile
• Short-term problem selecting radio network technologies and QoS levels• Objective function associated with
– Utility deriving from the assignment to QoS levels • utility volume = user benefit
– Cost deriving from the assignment to QoS levels and networks • Constraints the assignment to acceptable QoS and cost levels
Session Manager Core Functionality
Service Request (Applications, QoS
levels, etc.)
18
Interface Session and Network Manager
• From session manager– Load, performance and
QoS information for the service area region
– Alarms on degradations• From network manager
– New solutions– Allocations to networks
and QoS levels
TSMS Managed Networks(GPRS, WLAN, DVB-T)
NSMS Structure
Session Manager
Network Manager
RMS-RATDPRMS-RATDP
MonitoringMonitoring
RMS-RATIPRMS-RATIPResource Brokerage Service Management
(RBSM)
Resource Brokerage Service Management
(RBSM)
10
19
Network Managers
• Monitor managed network infrastructure
• Assess network and service level performance
• Decide (mid-term process)– Application
configuration– Traffic distribution– Network configuration
TSMS Managed Networks(GPRS, WLAN, DVB-T)
NSMS Structure
Session Manager
Network Manager
RMS-RATDPRMS-RATDP
MonitoringMonitoring
RMS-RATIPRMS-RATIPResource Brokerage Service Management
(RBSM)
Resource Brokerage Service Management
(RBSM)
20
Network Manager – RBSM
• Resource Brokerage– Enables cooperation of
NPs of the composite radio infrastructure
– Exchange and negotiationon a set of offers
• Service Management– Proactive behavior
• Invoked when new applications introduced
– Description of situation to be addressed
• Applications• User Class profiles• Terminal profiles• Demand volume
TSMS Managed Networks(GPRS, WLAN, DVB-T)
NSMS Structure
Session Manager
Network Manager
RMS-RATDPRMS-RATDP
MonitoringMonitoring
RMS-RATIPRMS-RATIPResource Brokerage Service Management
(RBSM)
Resource Brokerage Service Management
(RBSM)
11
21
Network Manager – Monitoring – GPRS
• Parameters– Dedicated Time Slots
(TSs) for GPRS traffic– Average available TSs– Load for GPRS traffic
(Requested data channels for GPRS usage - Average used downlink TS)
– Circuit switched traffic load
– Downlink throughput per TS (Data throughput per TS – TS throughput value)
– Successful packet channel allocation
• Alarm generationTSMS Managed Networks(GPRS, WLAN, DVB-T)
NSMS Structure
Session Manager
Network Manager
RMS-RATDPRMS-RATDP
MonitoringMonitoring
RMS-RATIPRMS-RATIPResource Brokerage Service Management
(RBSM)
Resource Brokerage Service Management
(RBSM)
22
Network Manager – Monitoring – WLAN
• Parameters– Total Received
Counter (bytes)– Total Transmitted
Counter (bytes)– Error count– Failed count (Loss)– Retry count– Polling interval
• Processing of SNMP MIBs
Network Manager
TSMS Managed Networks(GPRS, WLAN, DVB-T)
NSMS Structure
Session Manager
RMS-RATDPRMS-RATDP
MonitoringMonitoring
RMS-RATIPRMS-RATIPResource Brokerage Service Management
(RBSM)
Resource Brokerage Service Management
(RBSM)
12
23
Network Manager – Monitoring – DVB
• Indicative parameters– Total Bit Rate
• 24 Mbps– Useful Bit Rate
• TV services and IP data
– Residual Bit Rate per PID
• Available bit rate• Processing of SNMP MIB
TSMS Managed Networks(GPRS, WLAN, DVB-T)
NSMS Structure
Session Manager
Network Manager
RMS-RATDPRMS-RATDP
MonitoringMonitoring
RMS-RATIPRMS-RATIPResource Brokerage Service Management
(RBSM)
Resource Brokerage Service Management
(RBSM)
24
Network Manager – RMS
• Output of optimisation process– Application configuration– Traffic distribution to the
composite radio infrastructure
– Network configuration• RMS-RATIP functionality
– Mid-term process– Optimisation problem targets
• Assignment of applications to quality levels
• Assignment of traffic to networks of the composite radio infrastructure (Traffic distribution)TSMS Managed Networks
(GPRS, WLAN, DVB-T)
NSMS Structure
Session Manager
Network Manager
RMS-RATDPRMS-RATDP
MonitoringMonitoring
RMS-RATIPRMS-RATIPResource Brokerage Service Management
(RBSM)
Resource Brokerage Service Management
(RBSM)
13
25
Trigger(Applications, QoS levels,
profiles, demand, etc.)
Status and policies of originating NP
Offers of cooperating NPs
OptimisationProcess
Allocation of demand to networks
Allocationto quality levels
RMS-RATIP functionalityConstraints
Network Manager - RMS-RATIP functionality – (1)
• Trigger– describes the situation to be resolved – provides information on applications, QoS levels, profiles, etc.
26
Trigger(Applications, QoS levels,
profiles, demand, etc.)
Status and policies of originating NP
Offers of cooperating NPs
OptimisationProcess
Allocation of demand to networks
Allocationto quality levels
RMS-RATIP functionalityConstraints
Network Manager - RMS-RATIP functionality – (2)
• Constraints derive from– Status and policies of the originating network, e.g., capacity of
originating network, etc.– Offers, e.g., capacity that can be provided by the cooperating network,
etc.– Trigger, e.g., candidate QoS levels, cost levels, available networks, etc.
14
27
Trigger(Applications, QoS levels,
profiles, demand, etc.)
Status and policies of originating NP
Offers of cooperating NPs
OptimisationProcess
Allocation of demand to networks
Allocationto quality levels
RMS-RATIP functionalityConstraints
Network Manager - RMS-RATIP functionality – (3)
• Optimisation maximises objective function consisting of two terms:– Utility deriving from the assignment to QoS levels
• utility volume = user benefit and NP benefit– Costs from the assignment to QoS levels and NPs
28
High-level NSMS OperationWLAN Radio and
Fixed Network Manager
WLAN Radio and Fixed Network
Manager
DVB Radio and Fixed Network
Manager
DVB Radio and Fixed Network
Manager
Session Manager
(G)
Session Manager
(G)RBSM
(G)RBSM
(G)RMS-RATIP
(G)RMS-RATIP
(G)MSPSM
(G)MSPSM
(G)RMS-RATDP
(G)RMS-RATDP
(G)
GPRS Radio and Fixed Network Manager
TSMSTSMS
4.Offer exchange phase
3.Network status acquisition phase (monitoring) and load evaluation
2.User related information collection
1.Identification of new environment condition
5.Assignment of applications to QoSlevels and traffic to
networks
6.Acceptance phase
7.Session Manager Notification phase
8.Traffic distribution phase
15
29
Terminal Station Management System (TSMS)
30
Objectives
• Definition of hardware and software architecture for IP based services on a composite radio environment
• Development of terminal functionality for inter-system handover– Mobile IP
• Development of TSMS– Conducts decisions regarding the most appropriate network at
each moment.– Interface to applications.– Interface to NSMS.– Terminal monitoring.
16
31
Terminal Architecture
CREDO NSMS
CREDO TerminalCREDO application
TSMS
CREDO application
Legacy serv. support
TCP/IP stack
WLANdriver
GPRSdriver
DVB-Tdriver
Session Manager
CTNP:TSMS - NSMS
protocol
TSMS User Interface
CATP: Applications -
TSMS API
32
Terminal Hardware – a paradigm -
• Choices: – Linux based laptop, PDA, desktop.
• Network interfaces– IEEE802.11b PC Card– GPRS phone over serial line or GPRS PC Card– USB DVB-T receiver
• Issues:– No support for USB DVB-T devices on Linux: only PCI DVB-T
receivers are supported• Two test terminals for developments:
– Desktop computer with IEEE802.11b, GPRS and DVB-T support.– Laptop computer with IEEE802.11b and GPRS support.
17
33
Terminal Hardware – a paradigm -
• Foreseen CREDO Terminal– Desktop-based with WLAN (PCMCIA),
DVB (PCI), GPRS (Phone)• Reduced-size terminal (ex.: m-ToGuide) would
be more interesting– External DVB Rx connected with central
processor (with GPRS / WLAN) • ‘Converting’ part of capital expenditures onto
services– TSMS porting on Windows Portable
Computer (PDA)Pocket PC 2002 OS (Windows possible)240x320 color LCD displayIntegrated radios:
802.11bGSM/GPRSClass 2 Bluetooth
Internal AntennasUSB Support possible:
Connecting external DVB
34
TSMS Software ArchitectureCREDO TerminalCREDO
NSMS
TSMS
Network Selector.Decision mechanism
Handover middleware
Mobile IP
Network interface support
WLANsupport
GPRSsupport
DVB-Tsupport
Mobile IP NAT traversal
WLANdriver
GPRSdriver
DVB-Tdriver
CREDO applications
Legacy services(Generic ISP services)
Legacy service support
Session Manager Interaction
Service interface
User interface
Session Manager Quality monitor
TCP/IP stack
CATP: Applications -
TSMS
CTNP:TSMS - NSMS
protocol
18
35
TSMS Interfaces
• Interface with the NSMS: CTNP– Service Contract Information Request/Reply– Service Request/Reply– Quality Report Request/Reply– Handover Required Notification– Error messages
• Interface with the applications: CATP– Application Service Request– Network Ready– Application Keep Alive– Application Termination– Error messages
36
Network Selector (1)CREDO TerminalCREDO
NSMS
TSMS
Network Selector.Decision mechanism
Handover middleware
Mobile IP
Network interface support
WLANsupport
GPRSsupport
DVB-Tsupport
Mobile IP NAT traversal
WLANdriver
GPRSdriver
DVB-Tdriver
CREDO applications
Legacy services(Generic ISP services)
Legacy service support
Session Manager Interaction
Service interface
User interface
Session Manager Quality monitor
TCP/IP stack
Network Selector• Core TSMS module.• Stores TSMS data shared
by all modules.• Takes handover decisions.
19
37
Network Selector (2)
• Stores TSMS data shared by all modules:– Networks information:
• Available network list.• Preferred network list.• Currently selected network.
– Services information:• Service definition list.• Service instance list.
– Quality information:• IP parameters.• Link layer parameters.
• Receives events from the other modules– Application service requests and termination messages.– Service Replies from the Session Manager.– Network availability/unavailability notifications.– Handover status.– Quality information.
38
Handover Middleware (1)CREDO TerminalCREDO
NSMS
TSMS
Network Selector.Decision mechanism
Handover middleware
Mobile IP
Network interface support
WLANsupport
GPRSsupport
DVB-Tsupport
Mobile IP NAT traversal
WLANdriver
GPRSdriver
DVB-Tdriver
CREDO applications
Legacy services(Generic ISP services)
Legacy service support
Session Manager Interaction
Already available. Not CREDOProvided by Motorola
Developed in other WPsDeveloped in WP3
Service interface
User interface
Session Manager Quality monitor
TCP/IP stack
Handover Middleware• Network availability detection• Mobile IP• MIP NAT Traversal• Network driver configuration
20
39
Handover Middleware (2)
• Based on MNM libraries:– Mobile IPv4 Mobile Node implementation.– DHCP and Agent Discovery.– IEEE802.11b support
• Sub-modules:– Mobile IP NAT Traversal
• Implementation according to draft-ietf-mobileip-nat-traversal-07 (approved as Proposed Standard, RFC edition pending)
– GPRS and DVB-T support.
40
Quality Monitor (1)CREDO TerminalCREDO
NSMS
TSMS
Network Selector.Decision mechanism
Handover middleware
Mobile IP
Network interface support
WLANsupport
GPRSsupport
DVB-Tsupport
Mobile IP NAT traversal
WLANdriver
GPRSdriver
DVB-Tdriver
CREDO applications
Legacy services(Generic ISP services)
Legacy service support
Session Manager Interaction
Service interface
User interface
Session Manager Quality monitor
TCP/IP stack
Quality Monitor• IP parameters• Link layer parameters
21
41
Requirements for Quality Monitor (2)
• Monitor quality related parameters from the radio to the application level.
• Aggregate this information by creating a transparent, composite-radio wireless monitoring interface.
• Process the information in order to:– Indicate services actual perceived quality.– Indicate the cause of possible perceived quality problems.
• Provide interfaces in order to optimally configure network stackand application, based on the current radio conditions. I.e. specific WLAN, GPRS, DVB-T vertical (from radio to application level) configuration
42
Quality Monitor (3)
• IP parameters– Downstream and upstream data rates
• GPRS parameters– MSCoT (MultiSlot Class of Terminal)– Receiver power
• IEEE802.11b parameters– Nominal bit rate– Signal level– Noise level
• DVB-T parameters– Bit error rate– Signal strength– Receiver flags
22
43
Quality Monitor (4)
Input: parameters (network + application level)
WLAN DVB-T GPRS
CREDO applications
IP
TCP UDP
Parameters monitoring sub-moduleParameters monitoring sub-module
Parameters processing sub-moduleParameters processing sub-module
Output:Radio/TCP-IP/Apps re-configuration commands
TSMS Quality monitoring module
TSMS Network Selector: Decision mechanism
44
Quality Monitor (5)
• Parameters monitoring mechanism sub-module:– Implements the interface between the Quality Monitoring module
and the network and application. – Collects information vertically from all layers, in a polled or interface
driven manner. – The interfaces it implements are different, depending on the layer it
is communicating with.• Parameters processing sub-module:
– Process the collected monitored parameters in order to provide meaningful results about the perceived quality, the overall network status and the causes of possible problems.
– Issue reconfiguration commands in order for each of the network layers to be optimally configured for the current conditions.
• TSMS network selector module:– Decide about handover actions.
23
45
User InterfaceCREDO TerminalCREDO
NSMS
TSMS
Network Selector.Decision mechanism
Handover middleware
Mobile IP
Network interface support
WLANsupport
GPRSsupport
DVB-Tsupport
Mobile IP NAT traversal
WLANdriver
GPRSdriver
DVB-Tdriver
CREDO applications
Legacy services(Generic ISP services)
Legacy service support
Session Manager Interaction
Service interface
User interface
Session Manager Quality monitor
TCP/IP stack
User Interface• TSMS configuration• TSMS status:
• Available networks• Current network• Current services
46
Operational Scenario-Terminal Initiated Optimisation-
Service and ContentProvider
Service and ContentProvider
IP-basedFixed Network
IP-basedFixed Network
Radio Networks(GPRS, WLAN, DVB)
Radio Networks(GPRS, WLAN, DVB) N S M SN S M S TSMSTSMS
2. Information Request
2a. Information Provision
1. Identification of condition that can
require change of the radio access technolodgy
3. Information Acquisition PhaseThe NSMS prepares a reply to the TSMS, potentially by cooperating with the managed radio and fixed network
4. The TSMS selects the best radio access
technolodgy based on quality and cost criteria
5. Reconfiguration PhaseThe TSMS and NSMS cooperate and reconfigure the terminal, the radio network, the IP-based fixed network and the service and content provider servers
24
47
Application Aspects- A Test Case -
48
Service framework
Services based on both• multimode-specific applications interfacing to the rest of the system
1. The Sports Events information retrieval application2. The Video Streaming application
• Important existing Internet (‘legacy’) applications3. Through a collective ‘umbrella’ called Generic Internet Services
Each of 1-3 yields two services (of different QoS): low & high– high: greater average data rate, smaller delays (than low)
Simultaneous service reception at a terminal is possible– Following Internet paradigm
Association of services to users: through Service Contracts
25
49
Service contracts
Formal definition: a vector of service descriptorsService_Contract = (Service_1, …, Service_N)
Service contract examples:• (Sports Events High, Video Streaming High, Generic ISP High)
– ‘premium’ contract, with all services registered as high quality• (Sports Events High, Video Streaming Low, Generic ISP High)
– ‘fast Internet’ contract, with all services except Video Streaming registered as high quality
• (Sports Events Low, Generic ISP Low)– ‘basic Internet access’ contract, with Sports Event and ISP
registered as low quality (and the Video Streaming not registered at all)
Tailor-made protocols (CTNP,CATP) provide facilities compliant with the notion of service contracts
50
Service Definition in Composite Radio Environment
: (IP src, IP port) | (OWD, ipdv) Extra parameters(Currently not used)
Optional parameters
: QoS Level AQ1: (Average Bandwidth, burst size), …QoS Level List
: (Application, network1, network2, …), …Candidate Network (Technology) List
: (Application, QoS level, Cost ), …Cost Related Parameters
:(Application A1, QoS Level AQ1), … , (Application An, QoS Level AQm) QoS Related Parameters
: Application or a Set of applicationsSet of applications
Service Identifier
ParametersSERVICE
DEFINITION
26
51
Indicative list of Services
WLAN, GPRS(642, high)Generic ISP
-Low Quality
WLAN, GPRS, (DVB-T?)(512, high)
Set of legacy applications
Generic ISP-
High Quality
WLAN, GPRS,(642, high)Sports Event
-Low Quality
WLAN, (DVB-T?), GPRS,(256, high)
Sports events application
Sports Event-
High Quality
WLAN, (DVB-T?), GPRS(64, moderate)Video Streaming
-Low Quality
WLAN, DVB-T, GPRS(256, moderate)Video streaming
application
Video Streaming-
High Quality
Available networks(GPRS | WLAN | DVB-T)
QoS parameters(Average Bandwidth, burst size)
(kpbs,low/moderate/high)
Application/
Set of applicationsService
52
Overall Architecture
• RS 6000 system running AIX version 5.1 • Database content stored in IBM DB2 version 7.2• Application server version 4.0 and Video Charger Server 8.1• Java enabled WWW Client, using HTTP, RTP to retrieve
content• Video streaming performed using RTP protocol
Sports eventsSports events& &
Video ContentVideo Content
SQL request
XML reply
Content Generation
Pool of beans
ServerTransforms
Request interpretation
CREDO CREDO NetworkNetworkClientClient
HTTP Request
Sports eventsSports events& &
Video ContentVideo Content
SQL request
XML reply
Content Generation
Pool of beans
ServerTransforms
Request interpretation
CREDO CREDO NetworkNetworkCREDO CREDO NetworkNetworkClientClientClientClient
HTTP Request
27
53
Applications –TSMS interface
• Application and TSMS exchange through CATP:– Information transparent from the specific network technology currently
used.– TSMS is applications mediator to NSMS, hiding composite radio system
details.• Information exchanged:
– Application Service request: initialisation message that indicates the required by the application resources
– Network ready: indicates successful or unsuccessful resource allocation– Application keep alive: indicates the status of the application (still running,
enjoyed QoS)– Application service termination: indicates normal exit of the application and
leads to correct de-allocation of the resources– Error message
ApplicationsTSMS NSMS
CATP CTNP
54
Interaction
CATP CTNPAppl. Client
App. Server
Video AVH
TSMS NSMS
VL………
Appl. Service Req. (VH).
Network Ready (negative)
Appl. Service Req. (VL).
Network Ready (positive)
TSMS Service Req.(VL,networks,…)
Service Reply(networks,cost,…)
Video BVL
Scenario B
Scenario A
Content
System ViewVideoVH/L
28
Mobility Issues- paradigm -
56
Composite Radio Network Architecturein an IP Environment
Home Agent
NSMS
IP network (private and public segments)
SP IPbackbone
Application server
SP IPbackbone
Application server
Local IP infrastructure
Local NSMS
Foreign Agent
Access Router
NAT
WLAN APsand DHCP servers
Local IP infrastructure
NAT
GGSN
GPRSNetwork
Local NSMS
Local IP infrastructure
Local NSMS
Access Router
IP/DVB Gateway
DVB-T transmitter
WLAN SegmentWLAN Segment GPRS SegmentGPRS Segment DVBDVB--T SegmentT Segment
Smart Terminal
29
57
Composite Radio Network Architecturein an IP Environment
DVB return path (tunneling method) for IP protocol (Return path from WLAN / GPRS , NAT compatibility)
DVB IP space and assignment mechanism in a MS. (NSMS usage or DHCP in DVB segment)
DVB-T segment
Network deployment – AP placing, network naming (ESSID) and frequency assignment.
WLAN IP space and assignment mechanism (DHCP server or relay, NAT etc.)
WLAN segment
GGSN: element that provides the interface to external PDNsPDP (Packet Data Protocol) context creation procedureIP address of a MS & NAT mechanism
GPRS segment
IP architecture main componentsNetwork Segment
58
Network issues• Inter-system handover
– Mobile IPv4– A specific IP micro-mobility protocol is not necessary,
since Mobile IPv4 is only used for inter-system handovers
• NAT (Network Address Translator)– Most wireless operators (GPRS & WLAN) use NAT to
enlarge the available address space– “Plain” Mobile IPv4 incompatible with NAT– Solution: Mobile IP NAT Traversal IETF standard
• Unidirectional link– DVB-T links are unidirectional– UDLR or a similar solution will be used for automatic
configuration of a return path
30
59
NSMS-TSMS Interaction
• NSMS– Monitors the network state, and each terminal– Decides which terminal should use which network
• TSMS– Management software on the terminal
• NSMS-TSMS interaction is based mainly on two messages:– Service Request
• Sent from the terminal to the network to report available networks and running services
– Service Reply• Sent from the network to the terminal to tell the terminal which
network it should use.
60
Smart TerminalHome Address: H@. Key: ABC.
Home Agent
NSMS
IP network (private and public segments)
NSMS-TSMS Interaction (1)
SP IPbackbone
Application server
SP IPbackbone
Application server
Local IP infrastructure
Local NSMS
Access Router
NAT
WLAN APsand DHCP servers
Local IP infrastructure
NAT
GGSN
GPRSNetwork
Local NSMS
Local IP infrastructure
Local NSMS
Access Router
IP/DVB Gateway
DVB-T transmitter
WLAN SegmentWLAN Segment GPRS SegmentGPRS Segment DVBDVB--T SegmentT Segment
1. Starting point:
• The terminal has two available networks: WLAN and GPRS.• The currently selected network is WLAN. • The terminal is running one application. All application traffic is routed through the WLAN network.
Foreign Agent
31
61
Smart TerminalHome Address: H@. Key: ABC.
Home Agent
NSMS
IP network (private and public segments)
NSMS-TSMS Interaction (2)
SP IPbackbone
Application server
SP IPbackbone
Application server
Local IP infrastructure
Local NSMS
Access Router
NAT
WLAN APsand DHCP servers
Local IP infrastructure
NAT
GGSN
GPRSNetwork
Local NSMS
Local IP infrastructure
Local NSMS
Access Router
IP/DVB Gateway
DVB-T transmitter
WLAN SegmentWLAN Segment GPRS SegmentGPRS Segment DVBDVB--T SegmentT Segment
2. The TSMS sends a Service Request to the NSMS. The Service Request contains:
• The list available networks: GPRS and WLAN• The currently selected network: WLAN• The list of running services in the terminal
Foreign Agent
62
Smart TerminalHome Address: H@. Key: ABC.
Home Agent
NSMS
IP network (private and public segments)
NSMS-TSMS Interaction (3)
SP IPbackbone
Application server
SP IPbackbone
Application server
Local IP infrastructure
Local NSMS
Access Router
NAT
WLAN APsand DHCP servers
Local IP infrastructure
NAT
GGSN
GPRSNetwork
Local NSMS
Local IP infrastructure
Local NSMS
Access Router
IP/DVB Gateway
DVB-T transmitter
WLAN SegmentWLAN Segment GPRS SegmentGPRS Segment DVBDVB--T SegmentT Segment
3. The NSMS analyses the Service Request, and runs the optimisation algorithms taking into account the load of each access network and the services that each terminal is running. As a result the NSMS decides, for example, that this terminal should be switched to GPRS. The switch decision is notified using a Service Request message
Foreign Agent
32
63
Smart TerminalHome Address: H@. Key: ABC.
Home Agent
NSMS
IP network (private and public segments)
NSMS-TSMS Interaction (4)
SP IPbackbone
Application server
SP IPbackbone
Application server
Local IP infrastructure
Local NSMS
Access Router
NAT
WLAN APsand DHCP servers
Local IP infrastructure
NAT
GGSN
GPRSNetwork
Local NSMS
Local IP infrastructure
Local NSMS
Access Router
IP/DVB Gateway
DVB-T transmitter
WLAN SegmentWLAN Segment GPRS SegmentGPRS Segment DVBDVB--T SegmentT SegmentGPRS
interfaceIP@: B
PDP context creation
Foreign Agent
4. The terminal opens a PDP context on the GPRS link and obtains an IP address for the GPRS interface.
64
Smart TerminalHome Address: H@. Key: ABC.
Home Agent
NSMS
IP network (private and public segments)
NSMS-TSMS Interaction (5)
SP IPbackbone
Application server
SP IPbackbone
Application server
Local IP infrastructure
Local NSMS
Access Router
NAT
WLAN APsand DHCP servers
Local IP infrastructure
NAT
GGSN
GPRSNetwork
Local NSMS
Local IP infrastructure
Local NSMS
Access Router
IP/DVB Gateway
DVB-T transmitter
WLAN SegmentWLAN Segment GPRS SegmentGPRS Segment DVBDVB--T SegmentT SegmentGPRS
interfaceIP@: B
5. The terminal performs Mobile IP registration (Registration Request/Registration Reply) using the GPRS IP address as new CoA.
Foreign Agent
33
65
Smart TerminalHome Address: H@. Key: ABC.
Home Agent
NSMS
IP network (private and public segments)
NSMS-TSMS Interaction (6)
SP IPbackbone
Application server
SP IPbackbone
Application server
Local IP infrastructure
Local NSMS
Access Router
NAT
WLAN APsand DHCP servers
Local IP infrastructure
NAT
GGSN
GPRSNetwork
Local NSMS
Local IP infrastructure
Local NSMS
Access Router
IP/DVB Gateway
DVB-T transmitter
WLAN SegmentWLAN Segment GPRS SegmentGPRS Segment DVBDVB--T SegmentT SegmentGPRS
interfaceIP@: B
Foreign Agent
6. When the Mobile IP registration completes the traffic from the application is handed over to the new selected network.
FRAMEWORK FOR THE SYSTEM AND PERFORMANCE EVALUATION OF A COMPOSITE RADIO ENVIRONMENT
34
67
Presentation Overview
• A generic framework for defining basic experiment templates in composite radio platforms– Terminal-centric– Network-centric
• Components for experiment analysis and validation– Performance metrics for assessing congestion– Traffic models– High-level network segment models (DVB-T, GPRS,
WLAN)• Tools for traffic generation and analysis
68
Key Actions for short-term (terminal-centric) optimisation processes
• an intelligent multimode tagged terminal indicates to management a potential reason for short-term optimisation
– loss of coverage, or – increased congestion in the current radio segment, or – increased resource requirements due to initialisation of new
services, etc.• Management runs the appropriate radio optimisation
algorithm and identifies the suitable radio segment for serving the tagged terminal.
• Management notifies its suggestion to the tagged terminal. • Based on the information received from management, the
terminal decides on the most appropriate radio segment, which satisfies specific quality and cost criteria.
35
69
Key Actions for mid-term (network-centric) optimisation processes
• Management identifies that a radio segment has been congested and determines the appropriate redistribution of terminals (and the corresponding traffic load) over the segments.
• Management issues instructions for the execution of the decided redistribution.
• The involved intelligent multimode terminals follow the instructions.
70
Key Generic Items• Triggering event: The reason behind the invocation of short- or mid-term
optimisation processes. The triggering event defines the target/topic of an experiment.
• Environment conditions (in both pre- and post-experiment phase):– In the pre-experiment phase, they refer to the experiment setup (e.g., number of
terminals participating in the experiment, active services in these terminals, form and magnitude of background traffic, examined QoS parameters/metrics, etc.).
– The environment conditions in the post-experiment phase refer to a subset of the pre-experiment conditions depending in the nature of the experiment (usually, these conditions concern QoS parameters/metrics).
• Analysis of the experiment’s scenario: An analysis procedure for estimating/predicting the experiment’s dynamics, in both qualitative and quantitative terms (employs traffic and network modelling).
• Experiment realisation and data collection (key system actions): The set of key events associated with the specific experiment. This set includes internal TSMS/NSMS actions, exchanged messages and the output of optimisation algorithms.
• Analysis of the collected results (experiment analysis): The data collected during the experiment (as discussed in the previous item) are compared to:
– the estimates obtained from the qualitative analysis procedure with the objective of checking the correctness of system’s functionality and operations and
– the requested QoS levels (specified in the pre-experiment phase).
36
71
Experiment Templates – terminal centric
Move Terminal outside of coverage area
Terminal indicates modificationof its status
CRMS Runs OptimisationAlgorithms
Composite radio platformReconfiguration
Experiment SETUP
Log distribution of Terminals(and active services therein)
Log Applications Quality ParametersLog BG traffic
Log Applications QualityParameters
Key SystemActions
EnvironmentConditions
EnvironmentConditions
(Pre-experimentphase)
TriggeringEvent
ExperimentAnalysis
Logmessage
Logactions
Log messagesNew distribution of
Terminals
Check for the correctness of system operationsValidation of algorithm’s potential for
achieving QoS(Analyser involved)
Prediction of systemoperations
Increase BG Traffic(quantitative specification)
in radio segment used by theterminal
Open/Close a Service
72
Experiment Templates – network centric
Increase BG Traffic(quantitative specification)
in a specific segment
CRMS sensesQoS degradation
Composite radio platformReconfiguration
Experiment SETUP
Log distribution of Terminals and activeservices therein
Log Network Quality ParametersLog BG traffic
Log Network QualityParameters
Key SystemActions
EnvironmentConditions
EnvironmentConditions
(Pre-experimentphase)
TriggeringEvent
ExperimentAnalysis
Logactions
Log messagesNew distribution of
Terminals
Check for the correctness of system operationsValidation of algorithm’s potential for
achieving QoS(Analyser involved)
Prediction of systemoperations
37
73
A high-level terminal centric experiment• Triggering event
– A tagged terminal (TA) served by WLAN segment of a composite radio platform runs a high-quality video-streaming application (requiring a bandwidth of 768Kbps). According to two different experiment scenarios, alternatively:
• the terminal moves outside the coverage of WLAN, or • using appropriate traffic generators, the background traffic over the WLAN radio segment is increased (to become
1Mbps.). – In both cases TA senses QoS degradation.
• Environment conditions– Pre-experiment phase logs
• A composite radio platform with a WLAN and DVB-T segment.• WLAN_BgTraffic=0.5Mbps• The WLAN segment serves two multimode intelligent terminals: called TA and TB.• TA runs high-quality video-streaming service (Bandwidth =768Kbps).• TB runs low-quality video-streaming service (Bandwidth =128Kbps).• Application quality parameter = minimum throughput.
– Post-experiment phase logs• WLAN_BgTraffic=1Mbps• WLAN segment will serve CTB.• DVB-T segment will serve CTA.• Bit Rate for CTA.
• Prediction of system operations– The tagged terminal sends appropriate message to management indicating QoS degradation. – Based on the terminal’s message and the current traffic load in radio segments, management decides
that the DVB-T is the appropriate radio segment for the tagged terminal.– It answers to the tagged terminal with the appropriate reply message.– The tagged terminal switches to DVB-T.
74
Experiment analysis and validation
• traffic models to describe the load imposed on the segments of the composite network;
• network models to represent the mechanisms through which the network resources in each segment serve the traffic load; and
• performance metrics, obtained as output from analysis on the abovementioned models, for assessing network performance and quantifying congestion.
38
75
Performance metrics for use in models
A large number of elaborate metrics exist.HOW TO CHOOSE?
Requirement: Metrics must be simple (otherwise, very difficult to compute using tractable modelling techniques).Approach: Adopt simple service metrics such as the throughput and the delay.Effects: 1) Analytic solutions and cost-effective approximations based on measurable data,
2) Metrics relate directly to service-level QoS
Note that in all cases congestion is modelled by queueing phenomena
76
Performance metrics
In line with the QoS specification– A queueing delay percentile, specifying that
delay is not exceeded with probability >p– The long–term average-rate requirement
(matching the source’s mean rate) is guaranteed (statistically) through the stability condition of the queueing model, namely iff (traffic intensity < capacity)
39
77
Traffic Models
• Various types of data traffic loading the segments of the composite environment
• Circuit-switched (voice) traffic that shares network resources with data traffic over the GSM/GPRS cells
78
Traffic Models
• Circuit-switched services– A traditional birth-death process, with – speech and non-real time services arriving to the system
according to a Poisson process,– the service time (holding time) exponentially distributed.
• Packet traffic– Possible framework UMTS modelling framework where traffic at
packet level is bursty with silence durations corresponding to reading or silence periods and burst of packets at a variable size.
– Drawback: UMTS model can prove overly complex.– 1st Approach: Simplify using an MMPP process to describe bursty
packet traffic.– 2nd Approach: Use GE (still captures burstiness when first two
moments are known) as a further approximation/simplification in the absence of traffic data to map to all the parameters of an MMPP process
40
79
Traffic models – Data traffic•Capture burstiness(performance impact)•Use MM processes•Interest in ‘burst-level’ region
– Beneficial to employ fluid-flow simplification
•Upper left (low occupancy) – no apparent correlations•Lower right (burst level) –behaves as a continuous fluid with the same burst-level rate fluctuations and and constant rate values between fluctuations occurences
Buffer occupancy threshold x
log(
Pr
buffe
r oc
cupa
ncy
> x
)
burst scale
80
The Generalised Exponential (GE) distribution
The GE distributional model is• robust and • versatile • widely implemented in development of
analytical solution techniques for general (QNMs)
For C2>1 the GE model a mixed probability distribution interpreted as either
• extremal case of two-phase exponential distributions; or
• bulk type distribution with underlying counting process equivalent to CPP with geometrically distributed batch size
Note that GE distribution is versatile, possessing pseudo-memoryless properties making solution of GE-type queueing systems/networks analytically tractable.
M
αν ν = +
2 2 1 C
1 2 1 2 1
− = − +
α C C
α = +
2 2 1 C
2 2
2 2( ) 1 exp , 01 1
tF t tC C
ν = − − ≥ + +
41
81
The MMPP distribution
The Markov-modulated Poisson process (MMPP)
• qualitatively models the time-varying arrival rate,
• captures important correlation futures between interarrival times while still remaining analytically tractable.
The MMPP is the doubly stochastic Poisson process with the arrival rate given by [ ]* ( )J tλ , where ( )J t , 0t ≥ , is an m -state irreducible Markov process. By varying the arrival rate of a Poisson process according to an m -state irreducible continuous time Markov chain which is independent of the arrival process an MMPP can be constructed. When the Markov chain is in state i , arrivals occur according to a Poisson process of rate iλ . In general the model is described by the infinitesimal generator Q
1 12 1
21 2 2
1 2
m
m
m m m
Q
σ σ σσ σ σ
σ σ σ
− − = −
,
1
m
i ijjj i
σ σ=≠
=∑ ,
and the diagonal matrix with m Poisson arrival rates.
1 2( , , , )mdiag λ λ λΛ= … .
The steady-state vector of the Markov chain is π such that
0Q=π , 1π =e ,
where (1,1, ,1)T= …e is the column vector length m .
An interesting future of the MMPP is that the superposition of MMPPs is again an MMPP with
1 2 mQ Q Q Q= ⊕ ⊕ ⊕… ,
1 2 mΛ=Λ ⊕Λ ⊕ ⊕Λ… ,
where ⊕ represents the Kronecker-sum.
82
c
Network segment models
• Resources in each segment described in generic terms through a queueing model with M.M. fluid-flow input.
• In GPRS, additional complication due to varying CS traffic.– Separation of timescales (NCD
structure of model) exploited through decomposition/aggregation.
– Model yields simpler ‘submodels’ whose solutions are combined to yield the global one.
• Tail functions of queueing delay obtained from solutions of models (for GPRS under a mix of PS and CS load).
cV(t)r(t)
blockedGSM calls
Bursty arrivalprocess
NV GSM/GPRS Shared
(N-NV) GPRS dedicated
N Time Slots in cell
Packets queuedfor GPRS access
42
83
The GPRS model – approach 1
• Capacity for data modulated by presence of voice calls.– When J calls present, (N-J)c available to
serve data (c=capacity/TS)• For buffer occupancy, equivalent to
assume that each call contributes CBR data traffic of rate c.
• Input is superposition of ‘virtual’ voice traffic + data traffic.
• Time dynamics of voice traffic veryslower than those of data traffic. Decomposition possible (based on NCD theory).
• Split state space in ‘macroblocks’, each identifying activity under a constant number of voice calls J.– Frequent transitions within macroblock– Infrequent transition between
macroblocks
blockedGSM calls
Bursty arrivalprocess
NV GSM/GPRS Shared
(NV-N) GPRS dedicated
N Time Slots in cell
Packets queuedfor GPRS access
84
The GPRS model – approach 2
Transfer QueueAccess Queue
GSM voice traffic
GPRS
GPRS data traffic
GSM
GSM/GPRS cell modelled as• Two queueing sub-systems,
– one dedicated to voice traffic and – the other to data traffic
• Under partial sharing scheme (PSS) with – certain amount of channels dedicated for data traffic
and– remaining shared amongst voice and data traffic.
The cell partitions modelled as• The GSM Partition (a classical M/M/c/c loss system)
– Poissonian arrival process for voice traffic, – exponential call durations.
• The GPRS partition (GE/GE/1/N/FCFS GE/M/1/K/PS) – GE interarrival distributions for both external and
internal traffic. – Finite Capacity– FCFS access queue– PS (Processor Sharing) transfer queue (air interface)– GE is a versatile and tractable traffic model.
43
85
The DVB-T model – approach 1
• Dedicated PID for composite radio traffic.
• Constant fixed amount C of capacity guaranteed for this PID.
• The ‘generic’ FF queueingmodel applies directly:– MC rates describe
superposition of input traffic.
86
The DVB-T model – approach 2
µ=C/VBursty arrival process
G/G/1µ=service rateC=constant capacityV=packet size
DVB-T traffic futures
• Traffic is segmented in a number of groups.
• Each group is allocated some bandwidth.
• Each group operates independently.
DVB-T traffic model
• Focus on one group,• Adopt simple queueing model with
– general type of arrival process– service period with constant
capacity, C– variable packet size, V
• under FCFS service policy.
Note that queueing is kept back to the router when congestion
occurs
44
87
The WLAN model – approach 1
Complex EnvironmentDifficult to analyse directly
ApproachUse detailed model to derive throughput
metrics as values of virtual capacity which is state dependent on the number
of users and model
Note that queueing occurs at the entry buffers of the access point or a
router just before
CArrival processfor WLAN users
Access point
State dependent link Capacity, C(modeling WLAN congestion)
88
The WLAN model – approach 2
• Original capacity available, C• Fixed probability of packet
retransmissions (due to collissions/timeouts) (determined by detailed modeling/measurement of AP)
• In fluid setting, this results in a constant output capacity
• Use generic FF queueing model (as with DVB) with capacity
Access Point
Probability of retransmission, pR
C
M.M. bursty packetarrival process
C~
45
89
Tools for traffic generation and analysis
•traffic generator: load the network or inject monitoring test traffic•traffic analysers: capture the effect of congestion on selected traffic streams and provide through it measurements of performance metrics.
•Assist on dimensioning and on parameterization decision/optimisationalgorithms within network manager
N S M S
Ser v er
Tr affic
G en er ato r
IE E E 8 0 2 .1 1
D V B - T
G P R S
C redo Te rm i nal s
ho stin g T S M S
Analyzer
IP B ac k bo n e
A p plic atio n
Ser v er
O the r Te rm i nal s
Analyzer
N S M S
Ser v er
Tr affic
G en er ato r
IE E E 8 0 2 .1 1
D V B - T
G P R S
C redo Te rm i nal s
ho stin g T S M S
Analyzer
IP B ac k bo n e
A p plic atio n
Ser v er
O the r Te rm i nal s
Analyzer
90
BG traffic generators & analysers – simple examples
TG tools specifications:• TG should flexibly produce
very general traffic profiles,– based on built-in ‘canonical’
models– or (in ‘playback’ mode) read off
of a ‘log-file’ of stored traffic event descriptions (packet size & interarrival time traces)
• Thus may recreate traffic captured-processed by a traffic analyser
– may generate ‘test traffic’• TG could be combined (in
playback mode) with simulator, towards generating complex BG traffic effects
NetworkSimulator
Log file
Generator
Network
Analyzer
Traffic analysis/processing tools:• Standard Unix/Linux TCPdump
– may be hosted (as an external process) on top of (Linux-based) CREDO terminals