Transcript present

Seminar on ITU-T hot topics for
Standardization
(Mar del Plata, Argentina, 2
September 2009)
Interoperability technical means,
services, classes and parameters
of QoS
A. Koucheryavy, ZNIIS
General Director Advisor,
ITU-T SG11 Vice Chairman
Content
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
ITU-T activities
Testing methodology history
Technical means interoperability
Model Networks
The services interoperability
The QoS interoperability
DiffServ
IPTV traffic
Benchmarking
QoS classes
Conclusions
2
ITU-T activities
Resolution 76 “Studies related to
conformance and interoperability testing,
assistance to developing countries, and a
possible future ITU mark program” was
approved at the World
Telecommunication Standard Assembly
(Johannesburg, 2008).
3
“The interoperability of international
telecommunication networks was the
main reason to create ITU in the year
1865 (International Telegraph Union),
and that this remains one of the main
goals in the ITU strategic plan”.
4
What is the
interoperability today?
5
Recommendation Y.101 “Global
Information Infrastructure terminology:
Terms and definitions” Interoperability is
the ability of two or more systems or
applications to exchange information and
to mutually use the information that has
been exchanged”. This Recommendation
was approved at March 2000. It’s so long
ago from today point of view.
6
We will consider further interoperability
issues for the technical means, services
and QoS context on the base of the last
searching and developing progress and
Study Group 11 ITU-T activities. The main
focus for interoperability issues will be
interoperability supporting by testing
procedures.
7
The NGN concept is the real
implementation plan for network
modernization today. The full NGN
definition could be found in the
Recommendation Y.2001. The NGN concept
includes the some QoS guarantees levels
in according with Y.1540 and Y.1541 and
very widely services set, in principle
unlimited. Both of them points request to
consider interoperability as a complex
definition, including technical means,
services and QoS interoperability, not only
systems or applications.
8
The testing methodology history.
1.
2.
1995, ITU-T (X.290), ETSI (ETS 300406)
– conformance testing based on the
ISO/IEC 9646 and specific
telecommunication criteria and features.
1999, ETSI (TR 101667) – Network
Integral (Interconnection) testing (endto-end, node-to-node).
9
The conformance testing goal is the
specification profiles verification. The
network testing goal is the correct,
integrity and reliability services for users.
The table 1 ETR 101 667 defines the users
of both methodologies. The conformance
testing methodology users are the
vendors at first place and Administrations
and operators optionally, the network
testing methodology users are the
Administrations and operators only.
10
Technical means interoperability
The methodology of the model network
using for network testing was proposed
at ITU-T in 2004 (Q.39xx series).
The model network is the network, which
simulates the capabilities similar to those
available in present telecommunication
networks, has a similar architecture and
functionality and users, the same
telecommunication technical means.
11
The NGN testing experience.
ZNIIS Model Network (2004, Softswitch)
1016 tests – 8.1% unsuccessful tests
Plug Test ETSI (Slovenia, 2008, IMS)
410 tests – 18% unsuccessful tests.
(Joint ITU-T/ETSI meeting, Moscow,
ZNIIS, 10 April, 2009).
12
The Q.39xx Recommendation list.
Q.3900 – Model Network Architecture
Q.3901 – NGN (Softswitches)
Q.3903 – Data base
Q.3904 – NGN (IMS) (draft)
Q.3905 – IPTV
Q.3906.1 – Broadband access (wired)
(draft)
Q.3906.2 - Broadband access (WiFi)
(draft)
Q.3906.3 - Broadband access (WiMax)
(draft)
13
The services interoperability
testing
The ITU –T recommendations on the
services interoperability testing are
absent today. Furthermore, the service
scenarios for important NGN services are
absent too. It’s very complicated problem
today, but during ITU-T study period
2009-2012 the key recommendations set
for service interoperability testing should
be developed.
14









The detailed requirements for the services
implementation should be developed. It could be
include:
service definition and features;
network capabilities;
network architecture and function elements;
access network types and user equipments;
service delivery scenarios;
call flows;
reference points and protocols;
service implementation on the non-IMS network;
interworking with others services.
15
The testing scenarios, list and types of
tests for NGN TS1 basic call and
supplementary services, NGN TS1
streaming services and NGN TS1
multimedia services should be developed
as separately ITU-T Recommendations.
16
The Q.39xx recommendation list
(services testing)
Q.3915 – TS1 (draft)
Q.3916 – Testing scenarios, list and types
of tests for NGN (TS1) basic call and
supplementary services,
Q.3917 - Testing scenarios, list and types of
tests for streaming services (TS1),
Q.3918 - Testing scenarios, list and types of
tests for multimedia services (TS1).
17
The QoS interoperability
The many networks are realized NGN
concept. At first, of course, it’s the basic
IP network. Furthermore, it could be WiFi
(based on Ethernet technology), IPTV and
so on.
18
The some QoS mechanisms were
developed for QoS supporting at IP-based
networks. The recommendation Y.1291
which was approved in 2004 determine
four standardized approaches for QoS
supporting: Integrated services (IntServ),
Differentiated services (DiffServ),
MultiProtocol Label Switching (MPLS),
IPCablecom Dynamic QoS.
19
DiffServ
The service level agreement (SLA) concept
and the wireless broadband access
technologies development (WiFi and
WiMax) are shown, that DiffServ
mechanism could be using for QoS
supporting in the heterogeneous NGN
networks. If we can see the IEEE 802.11e
or QoS requests at the pooling-based
services for WiMax, we will found that the
QoS classes based on DiffServ concept.
20
There are three PHB classes:
 Assured Forwarding (AF PHB);
 Expedited Forwarding (EF PHB);
 Best Effort or Default PHB.
21
EF PHB is targeted to applications which
require strict guarantees of end-to-end
delay. The EF PHB applications request the
QoS level, which compare with the QoS
level for unloaded network.
22
AF PHB has been designed for a range
applications which require different QoS
guarantees. There are four classes of PHB
identification codes within the AF PHB
group. Within each class there are three
distinct DiffServ Code Points (DSCP) with
different packet drop precedence.
23
The mapping between Y.1541 QoS classes
and DiffServ mechanism are determined
in the recommendation Y.1291. The EF are
corresponding with Y.1541 classes 0 and
1, AF – classes 2, 3 and 4 respectively,
and Best Effort – class 5.
The mapping between VLAN (Virtual LAN
in accordance with IEEE 802.1) and
DiffServ DSCP are recommended in the
Y.2112.
24
IPTV traffic
The traffic flows types are really
complicated for NGN. They are
self-similar as usually. The selfsimilar traffic generation at the
model network is a real problem
today. We will consider IPTV traffic
further.
25
The IPTV traffic measurements was made
at ZNIIS model network. The actual traffic
of movies named Ohotnik, likely thriller
performed on DVD was analyzed for
differences times fragments and for
differences aggregation period in
processing of measuring data.
The minimum observation movies
fragment is the 60s. The fragment
includes 6863 frames, each of frame has
the length 1356 bytes
26
r
0 .8
0 .6
0 .4
0 .2
0
0
H=0.48
10
20
30
40
50
k
Autocorrelation function
Wavelet transform for Poisson traffic
28
min
max
Wavelet transform for measured traffic (fragment 60s)
29
The Q.39xx recommendations list
(for QoS testing)
Q.3919 – The types of traffic flows which should be
generated for voice, data and video on the Model
Network for testing QoS parameters.
Q.3920 – The types and list of tests for QoS
testing on Model networks for traffic-unloaded
conditions.
Q.3921 - The types and list of tests for QoS testing
on Model networks for traffic-loaded conditions.
Q.3922 - The types and list of tests for QoS testing
for intra-domain connectivity.
Q.3923 - The types and list of tests for QoS testing
for inter-domain connectivity.
30
Scenario Attempts per Second (SApS)
Benchmarking
135
14%
130
12%
125
10%
120
8%
115
6%
110
4%
105
2%
100
0%
0
10
System Load
20
30
Time (minutes)
Successful Scenario Attempts
40
50
60
% Inadequately Handled Scenario Attempts
COM 11-C33-E, SG11 meeting, 19-23 January, 2009, Geneva.
ETSI TS 186 008-1, October, 2007
31
Benchmarking Recommendations list
Q. Bench–IMS–NGN-A
IMS/NGN Performance
Benchmark Part 1:
Core Concepts
Q. Bench–IMS–NGN-B
IMS/NGN Performance
Benchmark Part 2:
Subsystem Configurations and
Benchmarks
Q. Bench–IMS–NGN-C
Q. Perf-Bench-IMS
IMS/NGN Performance
Benchmark Part 3:
Traffic Sets and Traffic Profiles
IMS/NGN Performance
Benchmark Part 4:
Delay objectives for various
IMS transactions
32
Q. Bench-PES NGN A
PES Performance
Benchmark Part 1:
Core Concepts
Q. Bench-PES NGN B
PES Performance
Benchmark Part 2:
Subsystem Configurations
and Benchmarks
Q. Bench-PES NGN C
PES Performance
Benchmark Part 3:
Traffic Sets and Traffic
Profiles
33
QoS classes
The six QoS classes from 0 to 5 are
defined at the table 2/Y.1541 “Guidance
for IP QoS classes” Recommendation
Y.1541.
34
The “0” QoS class contents real-time,
jitter sensitive, high interaction
applications. It could be VoIP and VTC
(Video Teleconference). The same
applications (VoIP, VTC) is the base for ”1”
QoS class, named “Real-time, jitter
sensitive, interactive” as we see, the
difference is only between “high
interactive” and “interactive”.
35
The Q.39xx recommendation list
(for VoIP testing)
Q. Perf-obj test VS IP
Network Performance
objectives Tests for
IP-based Voice
services
36
Conclusions.
1.
2.
3.
The main goal of testing today should be
network testing (interoperability) for
supporting the correct, integrity and
reliability services for users.
This goal could be supported by Model
network methodology.
The interoperability issues include the
technical means, services, QoS classes
and parameters. All of this features
create the Global Interoperability, which
could be tested on the Model network in
complex.
37