ETSI TS 102 675-1 V1.1.1 (2009-11)

Technical Specification
Satellite Earth Stations and Systems (SES);
Broadband Satellite Multimedia (BSM);
Part 1: Performance Management at the SI-SAP

2 ETSI TS 102 675-1 V1.1.1 (2009-11)

Reference
DTS/SES-00292
Keywords
architecture, broadband, management,
multimedia, satellite
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2009.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 102 675-1 V1.1.1 (2009-11)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 Objectives of performance management . 9
4.1 Performance Quality Assurance . 10
4.2 Performance Monitoring . 10
4.3 Performance Management Control . 10
4.4 Performance Analysis . 10
5 Information model for performance management . 10
6 Hierarchy (actors and roles) . 12
6.1 Performance Management Operations . 12
6.2 PM Roles . 12
6.2.1 PM traffic node (ST) . 13
6.2.2 PM server (B-NMS). 13
7 Management of BSM performance parameters . 14
7.1 BSM SI-SAP Performance Parameters . 14
7.1.1 Retrieving BSM SI-SAP Performance Parameters . 14
7.1.2 Calculating BSM SI-SAP Performance Parameters . 15
7.1.2.1 QID-level Performance Parameters. 15
7.1.2.1.1 List of IP flows associated to a QID [IP(QID )] and List of SD queues associated to a QID
i
[SD(QID )] . 16
i
7.1.2.1.2 Time from [t ] and type of [m ] last QID modification . 16
mod QID
7.1.2.1.3 Transmission Delay [D ] . 16
T
7.1.2.1.4 Maximum Hardware Delay [D ] . 17
hw
7.1.2.1.5 Rate [R]. 17
7.1.2.1.6 Slack Term [S] . 17
7.1.2.1.7 Traffic Pattern [r, b, p, m, M] . 18
7.1.2.2 SI-SAP-level Performance Parameters . 18
7.1.2.2.1 Number of active QIDs [N ] . 18
QID
7.1.2.2.2 List of QIDs [QID ] . 18
i
7.1.2.2.3 Available Data Rate [R ] . 18
ava
7.1.2.2.4 All-QIDs Transmission Delay [D ] . 18
T
7.1.2.2.5 All-QIDs Maximum Hardware Delay [D ] . 18
hw
7.1.2.2.6 All-QIDs Rate [R]. 18
7.1.2.2.7 All-QIDs Slack Term [S] . 18
7.1.2.3 Summary of QID Elementary Attributes . 19
7.2 BSM IP performance parameters . 19
7.2.1 Tools for Measuring BSM IP performance parameters . 20
7.2.1.1 RMON . 20
7.2.1.2 RTFM . 22
7.2.1.3 IPFIX . 22
7.2.1.4 PSAMP . 23
7.2.1.5 OWAMP . 23
7.2.2 Calculating BSM IP performance parameters. 24
ETSI
4 ETSI TS 102 675-1 V1.1.1 (2009-11)
7.2.2.1 Two-Measurement-Points BSM IP Performance Parameters . 24
7.2.2.1.1 IP Packet Transfer Delay (IPTD) and Delay Variation (IPDV) . 25
7.2.2.1.2 IP Packet Loss Ratio (IPLR) . 25
7.2.2.1.3 Spurious IP Packet Rate (SIPR) . 25
7.2.2.1.4 IP Packet Reordered Ratio (IPRR) . 25
7.2.2.1.5 IP Service Availability (IPSA) . 25
7.2.2.2 Single-Measurement-Point BSM IP Performance Parameters . 26
7.2.2.2.1 IP Packet Error Ratio (IPER) . 26
7.2.2.2.2 IP Packet Throughput (IPPT) and Goodput (IPPG) . 26
Annex A (informative): Examples of Performance Management tests . 27
A.1 Active measurements . 27
A.2 Passive measurement . 28
Annex B (informative): IETF MIBs and BSM Performance Objects . 29
History . 31

ETSI
5 ETSI TS 102 675-1 V1.1.1 (2009-11)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and
Systems (SES).
The present document is part 1 of a multi-part deliverable covering Performance Management aspects in "Satellite Earth
Stations and Systems (SES); Broadband Satellite Multimedia (BSM)", as identified below:
Part 1: "Performance Management at the SI-SAP";
Part 2: "Performance Management Information Base".
Introduction
The BSM Technical Reports [i.1], [i.2] and [i.3] outlined the general requirements for performance in BSM networks;
Technical Specifications [1] and [2] have subsequently defined the BSM Management Functional Architecture and the
BSM Performance Parameters respectively. Outside ETSI, ITU and IETF (in the IPPM working group) have also
defined a large number of richly parameterized metrics and protocols to deal with Performance Management (PM);
these parameters and protocols have been taken into account in defining BSM performance parameters ([2] gives
references to ITU and IETF metrics), and to define the PM strategies specified in the present document for BSM
networks.
As a result, the focus of the present document is on setting a clear framework of PM for BSM networks and on trying to
present all M-plane functions and instruments that can be used to manage the defined performance parameters.
ETSI
6 ETSI TS 102 675-1 V1.1.1 (2009-11)
1 Scope
The present document defines generic Performance Management in BSM networks based on the management
architecture given in [1].
The present document provides a framework for the possible Management-plane (M-plane) performance-related
strategies, functions, and protocols that can be used to monitor performance parameters in BSM networks.
Performance Management is here understood to be restricted to BSM network performance measurement and
monitoring with all associated supporting functions; this is better explained in clause 4.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI TS 102 672: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Management Functional Architecture".
[2] ETSI TS 102 673: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Performance Parameters".
[3] IETF RFC 1213: "Management Information Base for Network Management of TCP/IP-based
internets:MIB-II".
[4] IETF RFC 1445: "Administrative Model for version 2 of the Simple Network Management
Protocol (SNMPv2)".
ETSI
7 ETSI TS 102 675-1 V1.1.1 (2009-11)
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1] ETSI TR 101 984: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Services and architectures".
[i.2] ETSI TR 101 985: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia;
IP over Satellite".
[i.3] ETSI TR 102 157: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia;
IP Interworking over satellite; Performance, Availability and Quality of Service".
[i.4] ETSI TS 102 292: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM) services and architectures; Functional architecture for IP interworking with BSM
networks".
[i.5] ETSI TS 102 464: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Interworking with DiffServ Qos".
[i.6] IETF RFC 3289: "Management Information Base for the Differentiated Services Architecture".
[i.7] IETF RFC 3444: "On the Difference between Information Models and Data Models".
[i.8] ITU-T Recommendation M.3400: "TMN management functions".
[i.9] ITU-T Recommendation P.862 (02/2001): "Perceptual evaluation of speech quality (PESQ): An
objective method for end-to-end speech quality assessment of narrow-band telephone networks
and speech codecs".
[i.10] IETF RFC 2819: "Remote Network Monitoring Management Information Base".
[i.11] IETF RFC 3577: "Introduction to the RMON Family of MIB Modules".
[i.12] IETF RFC 2722: "Traffic Flow Measurement: Architecture".
[i.13] IETF RFC 2720: "Traffic Flow Measurement: Meter MIB".
[i.14] IETF RFC 3917: "Requirements for IP Flow Information Export (IPFIX)".
[i.15] IETF RFC 5101: "Specification of the IP Flow Information Export (IPFIX) Protocol for the
Exchange of IP Traffic Flow Information".
[i.16] RFC 5102: "Information Model for IP Flow Information Export".
[i.17] IETF RFC 5153: "IPFIX Implementation Guidelines".
[i.18] IETF RFC 5470: "Architecture for IP Flow Information Export".
[i.19] IETF RFC 5476: "Packet Sampling (PSAMP) Protocol Specifications".
[i.20] IETF RFC 5477: "Information Model for Packet Sampling Exports".
[i.21] IETF RFC 4656: "A One-way Active Measurement Protocol (OWAMP)".
[i.22] IETF RFC 1229: "Extensions to the generic-interface MIB".
[i.23] IETF RFC 2206: "RSVP Management Information Base using SMIv2".
[i.24] IETF RFC 2213: "Integrated Services Management Information Base using SMIv2".
[i.25] IETF RFC 2214: "Integrated Services Management Information Base Guaranteed Service
Extensions using SMIv2".
[i.26] IETF RFC 2863: "The Interfaces Group MIB".
ETSI
8 ETSI TS 102 675-1 V1.1.1 (2009-11)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in [1] and the following apply:
control plane: this has a layered structure and performs the call control and connection control functions; it deals with
the signalling necessary to set up, supervise and release calls and connections
management plane: this provides two types of functions, namely layer management and plane management functions:
- plane management functions: performs management functions related to a system as a whole and provides
co-ordination between all the planes
NOTE: Plane management has no layered structure.
- layer management functions: performs management functions (e.g. meta-signalling) relating to resources
and parameters residing in its protocol entities
NOTE: Layer Management handles the operation and maintenance (OAM) of information flows specific to the
layer concerned.
MIB: (also known as a managed object) one of any number of specific characteristics of a managed device
NOTE: MIBs comprise one or more object instances (identified by their OIDs), which are essentially variables.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in [1] and the following apply:
B-NMS BSM Network Management System
BSM Broadband Satellite Multimedia
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
FTP File Transfer Protocol
HTTP Hypertext Transfer Protocol
ICMP Internet Control Message Protocol
ICPIF Calculated Planning Impairment Factor
IETF Internet Engineering Task Force
IP Internet Protocol
IPFIX IP Flow Information Export
IPPM IP Performance Metrics
ITU International Telecommunications Union
MIB Management Information Base
MP Measurement Point
MOS Mean Opinion Score
NAP Network Access Provider
OID Object Identifier
OSS Operations Support System
OWAMP One-Way Active Measurement Protocol
PESQ Perceptual Evaluation of Speech Quality
PM Performance Management
QID Queue IDentifier
QoS Quality of Service
RFC Request For Comments
RMON Remote Network Monitoring
RTFM Realtime Traffic Flow Measurement
SLA Service Level Agreement
SNMP Simple Network Management Protocol
SNO Satellite Network Operator
ETSI
9 ETSI TS 102 675-1 V1.1.1 (2009-11)
ST Satellite Terminal
VoIP Voice over Internet Protocol
4 Objectives of performance management
Network performance management functionalities are shifting from relatively simple availability measurements to those
based on detailed Quality-of-Service (QoS) performance assessment. This is because network element availability is
generally high and stable, with hardware or software infrastructure failures occurring infrequently, but at the same time
increasing variety of traffic (e.g. voice, video and data), and multi-tiered applications have led to an increase in the
volume and complexity of network traffic.
Hence network management is moving from the limited perspective of "device-aware" network management to a focus
on service delivery - a "service-aware" perspective that is both more comprehensive and more cost-effective. Being
service-aware means that it understands the traffic flowing over the network. Once armed with that understanding,
traffic flows can be prioritised and devices configured based on the value and priority of the important traffic.
Whereas this is true as well for satellite as for terrestrial networks, normally the satellite link represents, from the
performance management point of view, the weak ring in the end-to-end chain; thus one of the key objectives of
Performance Management in satellite networks is ultimately to ensure that Service Level Agreements between the
satellite service provider (SNO, NAP, etc.) and other service providers are met. Hence the aspects of Performance
Management which are of interest to different actors in the network need to be taken into account here.
The objectives of Performance Management can be divided into the following categories (or function set groups
according to ITU classification - see [i.8]):
• Performance Quality Assurance.
• Performance Monitoring.
• Performance Management Control.
• Performance Analysis.
These categories will be briefly explained in the following sub-clauses highlighting those which are relevant for the
present document. It should be then clear to the reader that the document deals primarily with Performance Monitoring
and Performance Analysis (assessment) in BSM networks.
Network performance assessment is, to a greater of lesser extent, included within Performance Monitoring up to the
level of monitoring required. Network performance assessment is based on network traffic measurements, which can be
performed in two ways:
• with active measurements, which are performed by injecting traffic with known properties into the network;
and/or
• with passive measurements, which consist of monitoring the existing traffic flow(s) at one or more
measurement points.
Quality of Service (QoS) is one of the main objectives for network services and is often a main constituent of the SLA
of a given NAP. QoS is directly related to network performance. QoS measurement or assessment lies logically above
network traffic measurements, and relate to the performance of networking applications; they exploit the measurement
data to derive quantitative considerations on the "health" of the network:
• Objective QoS relates to something concrete and quantitative (e.g. packet loss, delay, jitter, connection break
length, etc.);
• Subjective QoS corresponds to the service quality from the user perspective (Mean Opinion Score (MOS) tests
are often used), subjective QoS can be estimated within certain limits from the basis of objective QoS
(e.g. PESQ algorithm [i.9]).
In any case the performance parameters to be considered in BSM networks for performance monitoring and assessment
are those described in [2]; they refer to layer-3 (IP-layer) parameters and only indirectly, through the BSM SI-SAP
parameters (which are generalized representations of specific SD features), to lower-layer parameters.
ETSI
10 ETSI TS 102 675-1 V1.1.1 (2009-11)
4.1 Performance Quality Assurance
Performance Quality Assurance supports decision processes that establish, according to current state-of-the-art, SLAs,
and customer needs, the quality measures that are appropriate for a correct performance management. It concerns
setting the alert thresholds, selecting the types of test to perform, the frequency with which to perform tests, etc.
It is up to the BSM network operator how to deal with these decisions and these functions will not be elaborated further
in the present document.
4.2 Performance Monitoring
Performance Monitoring involves the continuous collection of data from the BSM network elements. The basic function
of Performance Monitoring is to track system, network or service activities in order to gather the appropriate data for
determining performance of the BSM network.
The operation is designed to measure the overall quality of the network connections, using monitored parameters in
order to detect service degradation in a timely way. It may also be designed to detect characteristic patterns of
impairment before service quality has dropped below an acceptable level.
These are key operations to be considered when defining the M-plane functions in BSM networks; they will be
addressed in clauses 6 and 7.
4.3 Performance Management Control
Performance Management Control has two main functional areas: on one side it supports the transfer of information to
control the monitoring functions within the network; on the other side it includes the application of traffic controls to
guarantee a proper network operation in terms of performance.
For the former area, the Performance Management Control deals, for example, with configuration of measurement
schedules, sampling intervals, alert thresholds, and other attributes for monitoring and for test traffic, etc. These are also
key operations to be considered when defining the M-plane functions in BSM networks; they will be addressed in
clauses 6 and 7. The present document will mainly refer to this set of functionalities as "Performance Monitoring
Configuration".
The second functional area (enforcement of traffic control policies) may affect the shaping and/or routing of traffic and
the processing of flows. It is very much linked to BSM network operator strategies, so it is considered out of the scope
of the present document and it will not be elaborated further in the present document.
4.4 Performance Analysis
Performance Analysis processes the measurement data and evaluates the performance level of the network and its
elements.
This kind of analysis depends on, and it is in fact derived from, the type of measurement performed. It is up to the BSM
network operator how to define the necessary analysis to be applied on the performed measurements and this will not be
elaborated in details in the present document. Anyway since performance assessment is necessary up to a certain level
and it is part of Performance Analysis some considerations will be given in the clauses 6 and 7.
5 Information model for performance management
BSM Performance Management takes into account measurements at the IP-layer and at the SI-SAP interface between
the BSM and lower layers. Layer-2 issues and layer-2 Measurement Point s (MPs) will not be considered here; so
satellites with On-Board Processing (OBP), as layer-2 MPs, will not be considered in the present document.
ETSI
11 ETSI TS 102 675-1 V1.1.1 (2009-11)
Considering the BSM management functional architecture in [1], to simplify the discussion in the present document, it
is assumed that every BSM ST implements a standard MIB-II [3] and SNMPv2 agent [4] (or later versions). It is further
assumed that two types of database (D/B), D/B and D/B (see also figure 5.1), will be normally used in BSM networks.
1 2
D/B and D/B are understood to be combinations of databases (e.g. MIBs), both standard and proprietary ones, as it
1 2
will be explained in the following.
The internal format of D/B and D/B is not relevant for the scope of the present document. The present document is
1 2
only concerned with the type of information transferred between management functions to populate these databases, or
in other words the relationships (associations) between these entities and the roles identified in a BSM network.
D/B may contain a newly specified BSM-specific MIB, or MIB modules, as defined in part 2 of this multipart
deliverable. Part of these MIB modules are based on the BSM SI-SAP performance parameters defined in [2] and or
more basic QID elementary attributes identified in the present document. In addition D/B may contain other data
structures, e.g. technology or vendor specific ones.
D/B may also contain a newly specified BSM-specific MIB, or MIB modules, as defined in part 2 of this multipart
deliverable. Most likely this database will be based on the BSM IP performance parameters defined in [2]. In addition
D/B may contain other data structures, at wish of the BSM network operator. D/B is in fact the interface between the
2 2
BSM-internal and external worlds; it will most likely be a combination of data elements or data structures (some
standard ones, some proprietary ones, and some BSM-specific ones, as defined in part 2 of this multipart deliverable).
Visibility (read/write access rights) of the databases should be regulated by the BSM network operator; e.g. D/B may
or may not be made visible to external parties. In any case it should be noted that for specific data elements it may not
be possible to prevent external parties from directly polling D/B .
The set of element management data specified in part 2 of this multipart deliverable may be in the future formally
standardized as MIBs; in this case they should be provided by all BSM-compliant systems, so they will thus be accessed
by means of standard SNMP through the NMC (see figure 5.1). So service and network performance considerations can
be derived from it by aggregation and/or other types of analysis.
To OSS
BSM
BSM
BSM Mng . System
ST/GW/
NCC/OBP MF
SM
PM traffic node PM server
XIA
External
NM
http server https/XML http client
Management I/F
NMC
SNMP agent SNMP m‘ger
ASN.1/MIB
Private Data
IP ES/host IP ES/host EM
SM: Service Manager
NM: Network Manager
D/B
EM: Element Manager
D/B
MF: Management Function
XIA: External I/F Adaptor
Figure 5.1: BSM Management Functional Architecture
The BSM network should also foresee a central PM server which accomplishes its tasks interacting with PM modules
(or PM traffic nodes) located in the Satellite Terminals (STs). The server is responsible for selecting measurements to
be performed, configuring the PM nodes to perform them, for collecting the data, and for the final performance
assessment. The PM server may or may not be involved in the measurement as it is shown in figure 5.2. This
centralized architecture, where a central server is responsible for the PM in the network, seems quite suitable to a
satellite network.
ETSI
12 ETSI TS 102 675-1 V1.1.1 (2009-11)
Centralised
Monitor
(B-NMS)
QQooS MS Moonniittoorr & &
dadatatabbaassee
Performance
configuration &
Analysis
TTrraaffifficc TraTraffffiicc
mmeaseasururememeenntt
mmeeaassururemementent
ccoonnffiiggururatatiioon ann andd
ccoonnffiiggururaattiioon ann andd
cocolllleeccttiioonn cocolllleeccttiioonn
Traffic
ttrraaffifficc m meetteerriinngg ttrraaffifficc m meeteterriingng
ST(m)
ST(n)
Figure 5.2: Simplified BSM architecture for performance measurements
6 Hierarchy (actors and roles)
6.1 Performance Management Operations
The architecture presented in the previous clause can be considered a centralized architecture, as there is a central PM
server, located in the BSM Network Management System (B-NMS), and a number of managed network elements, the
PM traffic nodes, located in the STs. So there are two types of entities in a PM BSM architecture, and thus two PM
roles. For both of these roles the following four PM operations can be clearly identified:
• selection of the measurements to be performed;
• configuration of the PM nodes which perform them;
• measurements execution and collection of the data;
• final performance assessment.
They will be detailed clause 6.2.
6.2 PM Roles
The four operations listed above include a series of sub-tasks which should be performed by different entities in the
network (either by the PM server, or by the PM traffic nodes, or by both). In this clause we distribute these tasks to the
different PM roles in the network and describe the details.
ETSI
13 ETSI TS 102 675-1 V1.1.1 (2009-11)
6.2.1 PM traffic node (ST)
The following activities may be performed by the PM traffic node (ST) in the four operation areas identified above:
• Selection of the measurements to be performed: the ST should decide to perform selected measurements
independently only if this is required to populate local databases, or in order to fulfil requirements given by the
central PM server (e.g. keep a given parameter up-to-date).
• Configuration of the PM nodes which perform measurements: the PM traffic node may be pre-configured
with test applications, or may be completely configurable from remote (e.g. by RMON, [i.10]), both these
options are possible either for active and for passive measurements.
• Measurements execution and collection of the data: normally the ST will populate the database D/B with
the results of the performed measurements. The ST is involved in the measurement of parameters when (or
collection of measurement data):
- it is the only MP for the parameter, so the parameter is measured locally (e.g. number of active QIDs,
see [2]);
- it is involved in a measurement which takes place between multiple MPs, typically one-way
measurements (e.g. one-way delay by means of OWAMP, [i.21]);
- it is exporting data, which are collected by some other entities in the network, if, for example, IPFIX is
used, the ST will run an IPFIX exporter.
• Final performance assessment: not relevant for a PM traffic node.
6.2.2 PM server (B-NMS)
The following activities may be performed by the central PM server in the four operation areas identified above:
• Selection of the measurements to be performed: the PM server selects the metrics to be measured, i.e. the
singleton metrics (in IETF ippm terminology); it also decides the domain of measurement and the way of
sampling metrics:
- E.g. which STs? Which applications? Which network sections? Observation time, sampling period, etc.;
- Decides how to derive the sample metrics (in IETF ippm terminology).
• Configuration of the PM nodes which perform measurements: the PM server takes care of configuring the
PM traffic nodes to instruct them on how to measure parameters, either for passive monitoring or for active
measurements; if a pre-processing has to be done at the ST (i.e. on some sample metrics to derive statistical
metrics, in IETF ippm terminology) this is also configured by the PM server.
• Measurements execution and collection of the data: normally the PM server records the results of
measurements (the sample metrics in IETF ippm terminology), it processes the collected data for some
statistics (the statistical metrics in IETF ippm terminology), and writes them in the database D/B . It is also
involved in the measurement of parameters when (or collection of measurement data):
- it is involved in a measurement which takes place between multiple MPs, typically one-way
measurements (e.g. one-way delay by means of OWAMP, [i.21]); it may be frequent to involve the PM
server in one-way measurements;
- it is collecting data, which are exported by some other entities in the network (i.e. the PM traffic nodes),
if, for example, IPFIX is used, the PM Server will run an IPFIX collector (see clause 7.2.1.3 and the
figure therein).
• Final performance assessment: The PM performs all the relevant analysis on the collected data to derive
statistics and/or general considerations on the overall network performance, and calculation of SLA
compliance; if needed, it also performs some kind of pre-processing before writing the outcomes of this
analysis onto the database.
ETSI
14 ETSI TS 102 675-1 V1.1.1 (2009-11)
7 Management of BSM performance parameters
7.1 BSM SI-SAP Performance Parameters
As already mentioned, database D/B may be mostly based (even if not only) on the BSM SI-SAP Performance
Parameters defined in [2].
The BSM SI-SAP Performance Parameters have the following characteristics:
• They are BSM specific: They are associated to properties of the SI-SAP and in particular they describe
specific QIDs features, so they can be defined only for STs which implement the SI-SAP.
• They represent instantaneous values (like MIB parameters) and thus there is no need to track past parameter
values to compute one of these metrics.
• They can be measured at each SI-SAP in a BSM network, as a single point of measurement, i.e. at each ST or
gateway without involvement of external entities to support the measurement procedure (see [2] for more
details).
• They can be stored at each ST (where an SI-SAP is located) quite simply, by just measuring and immediate
storing the result of the measurement.
The present document defines performance management in a flexible way so that it can be implemented with a
minimum overhead requirement. In particular the latter three properties show that the monitoring of these parameters is
quite simple and does not add big complexity in the STs. In addition this shows that the BSM SI-SAP Performance
Parameters can be easily mapped to a MIB and be remotely retrieved by means of SNMP.
An ST with sufficient processing power may also generate statistics or tracking of selected parameters over time, as
well as other types of processing/aggregation of QID parameters. If the ST is capable of pre-processing, this should be
known to the B-NMS in advance in order to enable an efficient exchange of information, and avoid duplicating effort
(at the B-NMS there is no need of averaging multiple metrics retrieved from the ST, if an average was already
performed at the ST and the average value was transmitted). Pre-processing and statistics can be performed either over
time or over multiple QIDs for a given point in time, or over both time and QIDs, as it is shown in the three following
examples, which represent the three cases respectively:
1) Average number of open QIDs in the last hour.
2) Average Slack Term S over QIDs 1 to 5.
3) Average QID Rate R over the last hour for QIDs 6 to 10.
Given the very high number of possible combinations, by pre-calculating statistics of the basic BSM SI-SAP
performance parameters, many new "pre-processed" parameters can be created. These special parameters coming from
pre-processing and statistics are not standardized in the present document, implementers and operators are left free to
define the ones best suited to their management objectives.
7.1.1 Retrieving BSM SI-SAP Performance Parameters
Some of the parameters have only meaning locally to the ST, and for this reason a remote server (the B-NMS) has to
follow a clear procedure to retrieve them from an ST, in order to guarantee a proper system operation. In particular the
QID labels (or simply QIDs) are not sent over the air, and normally the QID value is not known to the B-NMS. So in
order to refer to (or to ask for) a specific parameter referred to a certain QID, the B-NMS has first to ask for the QID
label.
ETSI
15 ETSI TS 102 675-1 V1.1.1 (2009-11)
As described in [2], the BSM SI-SAP performance parameters can be divided in two classes: the SI-SAP-level ones and
the QID-level ones. The former ones have generally meaning for each ST, or for each BSM_ID, as they are defined
only if the SI-SAP exists, the latter ones have only meaning inside the ST, as they refer to QIDs and to local resources.
For this reason the former ones can be directly retrieved by the BSM network (i.e. the B-NMS) by simply addressing
the ST; on the other hand in order to retrieve the latter ones the BSM network needs to know the QID they are referred
to. So if the B-NMS is trying to get QID-level parameters, it should first retrieve from the ST the list of active QIDs;
once the B-NMS is aware of the QIDs available at an ST, it can ask for transmission of the specific QID-level
parameter(s). This procedure is depicted in figure 7.1.
From the figure it appears that it may not be easy to understand whether the QID label available at the B-NMS is
up-to-date or not: QIDs may change at the ST, be released and be created in the timeframe of minutes, hours, or days.
This timeframe may vary depending on the way the BSM network is managed, so the B-NMS should ask for updates of
the QIDs list according to these network characteristics. It may be also useful to piggyback the request for a QIDs list
update when the B-NMS is asking for other parameters, in order to have at the B-NMS information on the QID list as
up-to-date as possible.
Figure 7.1: Flow-chart of the BSM SI-SAP performance parameters retrieval procedure at the B-NMS
7.1.2 Calculating BSM SI-SAP Performance Parameters
In this clause clear indications are given on how to calculate BSM SI-SAP Performance Parameters.
7.1.2.1 QID-level Performance Parameters
Most of the QID-level parameters described in [2] can be extracted directly from measurements on the QIDs or should
be known to the ST by other means, e.g. through other local MIBs or by some intrinsic knowledge. In [2] it is also
described how to derive most of these parameters. Where they cannot be measured or extracted directly, a set of QID
elementary attributes can be used to derive these SI-SAP parameters. In the present clause the derivation of all SI-SAP
QID-level performance parameters is given and the list of the associated QID elementary attributes is derived.
ETSI
16 ETSI TS 102 675-1 V1.1.1 (2009-11)
7.1.2.1.1 List of IP flows associated to a QID [IP(QID)] and List of SD queues associated
i
to a QID [SD(QID )]
i
The List of SD queues associated to a QID [SD(QID )] is a list of SD labels, or technology- and system-dependent
i
codes, which should be known to the NCC, but may not be known to the B-NMS. So the B-NMS may have to
com
...