ETSI TR 102 807 V1.1.1 (2010-03)

Speech and multimedia Transmission Quality (STQ); Process description for the transaction view model

DTR/STQ-00161m

General Information

• Status: Published
• Publication Date: 17-Mar-2010
• Technical Committee: STQ MOBILE - STQ Mobile
• Current Stage: 12 - Completion
• Due Date: 22-Mar-2010
• Completion Date: 18-Mar-2010

Standards Content (Sample)

ETSI TR 102 807 V1.1.1 (2010-03)
Technical Report


Speech and multimedia Transmission Quality (STQ);
Process description for the transaction view model

---------------------- Page: 1 ----------------------
2 ETSI TR 102 807 V1.1.1 (2010-03)



Reference
DTR/STQ-00161m
Keywords
mobile, QoS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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 2010.
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

---------------------- Page: 2 ----------------------
3 ETSI TR 102 807 V1.1.1 (2010-03)
Contents
Intellectual Property Rights . 4
Foreword . 4
Introduction . 4
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.3 Abbreviations . 7
4 Deriving standardized triggers from existing QoS parameter definitions . 7
5 Defining a new set of QoS parameters and trigger events for a service . 8
5.1 General Rules . 8
5.2 Detailed Process Description . 9
6 Example: Using the process for Web Radio QoS parameters . 10
History . 18

ETSI

---------------------- Page: 3 ----------------------
4 ETSI TR 102 807 V1.1.1 (2010-03)
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 Report (TR) has been produced by ETSI Technical Committee Speech and multimedia Transmission
Quality (STQ).
Introduction
The present document describes, in a process-oriented fashion, how QoS parameters for a particular service can be
defined. It treats the relationship between transaction modelling and the point-of-observation view. Finally, it gives an
example on how a standard trigger event list can be derived from a QoS parameter definition.
This document accompanies a major undertaking aimed at a more formal definition of QoS parameters. Some early
groundwork was laid with the "generic transaction model" which introduced the idea of a hierarchical description of use
cases of particular services. In this model, the concept for what was later called "point of observation" had also been
drafted. The discussion about the required degree of seamlessness event flows related to QoS parameter was also part of
this general evolution process.
The following list describes the elements and development of the whole concept:
• Find a generic structure of service usage descriptions.
• Describe a single case of service usage as the basic transaction for a particular service.
• Describe transactions as consisting of phases.
• Propose a hierarchical model of transaction description, starting with the "user perception" which is starting
point and justification for any subsequent, eventually more refined description.
• Recognize that there are different points of observation (PCOs) on which events take place. Require that
trigger events used for a particular QoS parameter should, unless there is a grave reason to do otherwise, come
from the same point of observation.
In the end, the complete model has the following components
• For each service type, a formally clean definition of the basic transaction for that service, complete with a
definition of possible outcomes (results).
• For each transaction type, a clean, hierarchical description which links technical trigger events to relevant user-
perception events and QoS parameters description aspects of quality for that service.
• A pool of formally cleanly identified trigger events, and a definition of each event-based QoS parameter as a
function of such trigger points.
For the sake of easy and efficient implementation, it is desirable to have technical definitions with a structure as clear as
possible; most preferably, this structure should even have the form of a "formal language" allowing for automated
creation of technical implementations (e.g. as ASN.1 or XML).
ETSI

---------------------- Page: 4 ----------------------
5 ETSI TR 102 807 V1.1.1 (2010-03)
On the other hand, the "primary directive" for any QoS parameter is that it should represent "real user" perception of an
aspect of service quality. In other words, every QoS parameter should justify its existence by a clear relationship to such
user perception.
Unfortunately, formally strict systems have a tendency to become quite unreadable, or lose their easiness and elegance
by requiring a big overhead of rules to enable correct usage. .Therefore, it is a real challenge is to reach both goals of
formal strictness and clear relationship to user perception simultaneously. Purpose of this article is to show a way how
this can be done.
One should be aware, however, that there are also some primarily non-technical aspects which have to be considered:
• The underlying formal structure needs to work for all existing services, and will always be challenged with the
emergence of new services and their QoS parameters. It should be expected that therefore the methodology
itself will also evolve with time.
• Existing definitions are deeply entrenched, in processes and products and will produce inertia at best, and most
probably resistance, when it comes to changing "external" properties such as names or technical definitions.
Also, there is no immediate benefit of changes made here. Therefore, it is likely that there will always be "old
layers" of definitions and specifications.
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TR 102 807 V1.1.1 (2010-03)
1 Scope
The present document describes underlying concepts of formal description of QoS parameters for particular services,
and the way used by a task force within the STQ MOBILE working group to evolve the standards by a more formal
trigger point and QoS parameter definition.
The present document presents a process-oriented method to:
• Build a full framework of transaction definition, trigger event definition, and QoS parameter definition for a
(fictive) new service or to evolve a description for an existing service to a more formal shape
• Create trigger event lists from existing QoS parameter definitions, with Web Radio service as an example
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.
Not applicable.
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 TS 102 250-7: "Speech and multimedia Transmission Quality (STQ); QoS aspects for
popular services in GSM and 3G networks; Part 7: Network based Quality of Service
measurements".
[i.2] ITU-T Recommendation X.290: "OSI conformance testing methodology and framework for
protocol Recommendations for ITU-T applications - General concepts".
[i.3] ETSI TS 102 250-2: "Speech and multimedia Transmission Quality (STQ); QoS aspects for
popular services in GSM and 3G networks; Part 2: Definition of Quality of Service parameters and
their computation".
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TR 102 807 V1.1.1 (2010-03)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
phase: single component within a transaction having a clearly defined start and success criterion
transaction: complete sequence of phases which makes up a meaningful single activity from the customer's point of
view (example: speech call, ftp download)
trigger event: event used for definition of QoS parameters
EXAMPLE: Typical trigger events can be the reception of a protocol message in a protocol layer, or starting an
action done by a user or a machine.
trigger point: point in time when a trigger event occurs
NOTE: This may contain additional information.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
EPG Electronic Program Guide
PCO Point of Control and Observation
QoS Quality of Service
SAP Service Access Point
TCP/IP Transmission Control Protocol/Internet Protocol
TP Trigger Point
4 Deriving standardized triggers from existing QoS
parameter definitions
For preparation, a list structure is prepared having the following columns:
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TR 102 807 V1.1.1 (2010-03)
Field Description
TP ID Trigger point ID.
PCO PCO where the trigger event can be observed.
This identifies the event flow this QoS parameter belongs to (relevant for QoS
parameter sets which belong to different scenarios; the case of PoC is a good example
where multiple scenarios exist). Not required if all QoS parameter belong to the same
Scenario scenario.
Identifies the phase the respective QoS parameter belongs to. See the GTM model
description. For "old" QoS parameter where phase has not been directly identified, this
Phase field can be treated as optional.
Purpose of this field is to control automatic creation of QoS parameter by selection a
pre-defined pattern of trigger point processing.

Currently three different types are identified:
Ratio (tbd if further differentiation into Success Ratio and Failure Ratio is useful)
Basic processing: Start Trigger is "Try" element; Stop trigger is "Success" element).
Time: Basic processing: Time for each transaction is difference between timestamps of
stop and start trigger provided both are valid (i.e. time is valid only for successful
transaction).
Time Window: Start and Stop triggers denote the time window in which a third data
Type entity should be collected (e.g. sample MOS for audio speech quality).
TP def, customer view This links the technical trigger point to a meaningful event on the customer-view plane.
TP def, technical view Technical definition of the trigger point in terms of the respective PCO.
Ref: Ratio This fields should contain the clause numbers in the source document (e.g. TS 102
250-2 [i.3].
Ref: Time
NOTE 1: Document version identifier is also required in case that clause numbers vary
within document versions).
NOTE 2: This set of fields is meant to provide the easiest possible way to access the
Ref.: Time Window original QoS parameter definition for editing and reference purposes.

This list is used to receive all the information taken from the specification document.
The associated process is:
1) For each QoS parameter:
1.1 Create at least two list rows with respective information from the parameter definition (user perception
and technical definition of start and end (success) trigger).
1.2 Identify, for each row, the scenario to which the respective parameter belongs.
1.3 Identify the point of observation associated to the
...