1、 ETSI TR 102 807 V1.1.1 (2010-03)Technical Report Speech and multimedia Transmission Quality (STQ);Process description for the transaction view modelETSI ETSI TR 102 807 V1.1.1 (2010-03) 2Reference DTR/STQ-00161m Keywords mobile, QoS ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANC
2、E 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 enregistre la Sous-Prfecture 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
3、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
4、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 y
5、ou 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 reprod
6、uction in all media. European Telecommunications Standards Institute 2010. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its
7、 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 ETSI TR 102 807 V1.1.1 (2010-03) 3Co
8、ntents Intellectual Property Rights 4g3Foreword . 4g3Introduction 4g31 Scope 6g32 References 6g32.1 Normative references . 6g32.2 Informative references 6g33 Definitions and abbreviations . 7g33.1 Definitions 7g33.3 Abbreviations . 7g34 Deriving standardized triggers from existing QoS parameter defi
9、nitions 7g35 Defining a new set of QoS parameters and trigger events for a service . 8g35.1 General Rules . 8g35.2 Detailed Process Description 9g36 Example: Using the process for Web Radio QoS parameters 10g3History 18g3ETSI ETSI TR 102 807 V1.1.1 (2010-03) 4Intellectual Property Rights IPRs essent
10、ial 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 potentiall
11、y 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
12、 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 Speec
13、h 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 exampl
14、e 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 de
15、scription 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 followi
16、ng 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 trans
17、action 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
18、 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
19、 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
20、 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 autom
21、ated creation of technical implementations (e.g. as ASN.1 or XML). ETSI ETSI TR 102 807 V1.1.1 (2010-03) 5On 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 ju
22、stify 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 bot
23、h 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 ne
24、eds 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 pro
25、duce 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
26、 ETSI TR 102 807 V1.1.1 (2010-03) 61 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
27、 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
28、 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 refe
29、rence 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
30、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 do
31、cuments 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 referen
32、ced 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 Transmiss
33、ion 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
34、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 ETSI TR 102 807 V1.1.1 (2010-03) 73 Definitions and abbreviations 3.1 Definitions For the purposes o
35、f 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 customers point of view (example: speech
36、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 co
37、ntain 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 PointTCP/IP Transmission Control Protocol/Internet Protocol TP Trig
38、ger Point 4 Deriving standardized triggers from existing QoS parameter definitions For preparation, a list structure is prepared having the following columns: ETSI ETSI TR 102 807 V1.1.1 (2010-03) 8Field Description TP ID Trigger point ID. PCO PCO where the trigger event can be observed. Scenario Th
39、is 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. Phase Identifies the phase the respective
40、 QoS parameter belongs to. See the GTM model description. For “old“ QoS parameter where phase has not been directly identified, this field can be treated as optional. Type Purpose of this field is to control automatic creation of QoS parameter by selection a pre-defined pattern of trigger point proc
41、essing. 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
42、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 entity should be collected (e.g. sample MOS for audio speech quality). TP def, customer view This links
43、 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. NOTE 1: Document ver
44、sion 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 original QoS parameter definition for editing and reference purposes. Ref: Time Ref.: Time Window This list is used to re
45、ceive 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 Identi
46、fy, for each row, the scenario to which the respective parameter belongs. 1.3 Identify the point of observation associated to the technical trigger. 2) After completion of Step 1 for all QoS parameters, post-process the list created by identifying duplicate trigger points. Create trigger point IDs f
47、or every unique trigger point. 3) Create a list of all trigger points derived in Step 2 (this can e.g. be done implicitly by appropriate automatic processing of the list). 4) (prospective) Create a new version of the QoS parameter definitions where the parameter is described in terms of trigger poin
48、t IDs). 5 Defining a new set of QoS parameters and trigger events for a service 5.1 General Rules In order to decompose the use case(s) of a service into an appropriate hierarchy of transactions, finding suitable QoS parameters and the underlying events in a systematic way, a top-down approach has t
49、o be applied. Such a systematic top-down process description is the main topic of the “transaction view model“. ETSI ETSI TR 102 807 V1.1.1 (2010-03) 9On the other hand, hierarchies of definitions are by nature always bottom-up. E.g. in order to define a QoS parameter in terms of certain events, these events have to be defined beforehand. Thus, the whole process of creating appropriate definitions for (event-driven) QoS metrics of a new service may be summarized as first identifying a transaction hierarchy in a top-down decomposition and t
