ISO/IEC 29341-17-10:2011

ISO/IEC 29341-17-10
Edition 1.0 2011-09
INTERNATIONAL
STANDARD
colour
inside
Information technology – UPnP device architecture –
Part 17-10: Quality of Service Device Control Protocol – Level 3 – Quality of
Service Device Service
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester.
If you have any questions about ISO/IEC copyright or have an enquiry about obtaining additional rights to this
publication, please contact the address below or your local IEC member National Committee for further information.

IEC Central Office
3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: inmail@iec.ch
Web: www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
 Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
 IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
 Electropedia: www.electropedia.org
The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions
in English and French, with equivalent terms in additional languages. Also known as the International Electrotechnical
Vocabulary online.
 Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: csc@iec.ch
Tel.: +41 22 919 02 11
Fax: +41 22 919 03 00
ISO/IEC 29341-17-10
Edition 1.0 2011-09
INTERNATIONAL
STANDARD
colour
inside
Information technology – UPnP device architecture –
Part 17-10: Quality of Service Device Control Protocol – Level 3 – Quality of
Service Device Service
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
X
ICS 35.200 ISBN 978-2-88912-657-6

29341-17-10 © ISO/IEC:2011(E)
CONTENTS
1  Overview and Scope . 5
1.1  Referenced Specifications . 5
1.1.1  Normative References . 5
1.1.2  Informative References . 6
2  Service Modeling Definitions . 6
2.1  ServiceType . 6
2.2  State Vari ables . 7
2.2.1  XML Fragments as UPnP Arguments . 7
2.2.2  A_ARG_TYPE_TrafficDescriptor . 8
2.2.3  A_ARG_TYPE_TrafficDescriptorsPerInt erfac e . 8
2.2.4  A_ARG_TYPE_TrafficHandle . 10
2.2.5  A_ARG_TYPE_NumTrafficDescriptors . 10
2.2.6  A_ARG_TYPE_QosDeviceCapabilities . 10
2.2.7  A_ARG_TYPE_QosDeviceState . 11
2.2.8  PathInformation . 12
2.2.9  A_ARG_TYPE_QosDeviceInfo . 14
2.2.10  A_ARG_TYPE_QosStateId . 14
2.2.11  A_ARG_TYPE_NumRotameterObservations . 14
2.2.12  A_ARG_TYPE_RotameterInformation . 15
2.2.13  A_ARG_TYPE_ConfRotameterObservations . 20
2.2.14  MostRecentStreamAction . 21
2.2.15  A_ARG_TYPE_MaxPossibleRotameterObservations . 22
2.2.16  A_ARG_TYPE_Resource . 22
2.2.17  A_ARG_TYPE_AdmitTrafficQosExtendedResult . 23
2.2.18  A_ARG_TYPE_ListOfAdmittedTraffic . 26
2.2.19  A_ARG_TYPE_ PreferredQph . 28
2.2.20  UnexpectedStreamChange . 29
2.2.21  A_ARG_TYPE_PreemptingTrafficI nfo . 29
2.2.22  A_ARG_TYPE_ListOfMostRecentUnexpectedStreamChanges . 30
2.2.23  A_ARG_TYPE_QosDeviceExtendedSt ate . 33
2.2.24  A_ARG_TYPE_Layer2Mapping . 38
2.2.25  A_ARG_TYPE_AdmitTrafficQosSucceeded . 38
2.2.26  A_ARG_TYPE_TrafficDescriptorsWanted . 38
2.2.27  A_ARG_TYPE_SetPreferredQphResults . 38
2.2.28  A_ARG_TYPE_ NumberOfUnexpectedStreamChangesRequested . 39
2.2.29  A_ARG_TYPE_ NumberOfUnexpectedStreamChangesReported . 39
2.2.30  A_ARG_TYPE_NewTrafficLeaseTime . 39
2.2.31  A_ARG_TYPE_TrafficDescriptorContainer . 39
2.2.32  A_ARG_TYPE_Layer2MappingContainer . 41
2.2.33  A_ARG_TYPE_QosDeviceInfoContainer . 41
2.3  Eventing and Moderation . 43
2.3.1  Event Model. 43
2.4  Actions . 44
2.4.1  GetQosDeviceCapabilities() . 45
2.4.2  GetQosState() . 46

XXXX: © IEC:2010 — 2 — 29341-17-10 © ISO/IEC:2011(E)
2.4.3  SetupTrafficQos() . 47
2.4.4  ReleaseTrafficQos() . 49
2.4.5  GetPathInfor mation . 50
2.4.6  GetQosDeviceInfo() . 51
2.4.7  ConfigureRotameterObservation() . 52
2.4.8  GetRotameterInformation() . 53
2.4.9  AdmitTraffi c Q os (). 54
2.4.10  UpdateAdmittedQos() . 62
2.4.11  ReleaseAdmittedQos() . 65
2.4.12  GetExtendedQosState() . 67
2.4.13  SetPreferredQph() . 68
2.4.14  GetUnexpectedStreamChanges() . 70
2.4.15  VerifyTrafficHandle () . 71
2.4.16  UpdateTrafficLeaseTime () . 71
2.4.17  SetL2Map () . 72
2.4.18  Non-Standard Actions Implemented by a UPnP Vendor . 73
2.4.19  Error Code Summary . 73
2.4.20  Reason Code Summary . 74
2.5  Theory of Operation (Informative) . 75
2.5.1  Parameterized QoS . 77
2.5.2  Prioritized QoS . 80
2.5.3  Hybrid QoS . 81
3  XML Service De s c r iptions . 82
4  Test . . 88
Annex A (informative) Additional Examples for State Variabl es . 89
A.1  Additional PathInformation Examples . 89
A.1.1  Sample argument XML string – PC with two network interfaces that
are both end point device and brid ged . 89
A.1.2  Sample argument XML string –Four port Ethernet Switch . 89
A.1.3  Sample argument XML string – Wireless AP with one Ethernet
Interface . 90
A.1.4  Sample argument XML string – Bridge device between Wireless
station and Ethernet . 90
A.2  Additional A_ARG_TYPE_RotameterInformation Examples . 91
A.2.1  Sample argument XML string – PC with two network interfaces that
are both end point devices . 91
A.2.2  Sample argument XML string – PC with two network interfaces that
are both end point device with TrafficImportanceNumber reporting . 94
A.2.3  Sample argument XML string –Four port Ethernet Switch . 95
A.2.4  Sample argument XML string – Wireless AP with one Ethernet
Interface . 95
A.2.5  Sample argument XML string – Bridge device between Wireless
station and Ethernet . 96
Annex B (normative) Template for Requirements on the QosDevice Service
implementation that are specific for the underlying Network Technologies . 98
B.1  . 98
B.1.1  References . 98
B.1.2  Priority Mapping . 98
B.1.3  QosSegmentId formation . 98
B.1.4  Layer2StreamId representation . 99

29341-17-10 XXXX: © IEC:2010 © ISO/IEC:2011(E) — 3 —
B.1.5  Mapping of UPnP-QoS Parameters to Parameters . 99
B.1.6  Blocking traffic stream identification . 100
B.1.7  Responsibility for QoS Setup . 100
B.1.8  Mapping of Returned Parameters to ProtoTspec
Parameters . 101
B.1.9  Mapping of Returned Parameters to
AdmitTrafficQosExtendedResult and AllocatedResources
Parameters . 102

Figure 2-1 — Relationship between ROPeriod and MonitorResolutionPeriod . 16
Figure 2-2 — PC with Two Network Interfaces . 18
Figure 2-3 — Example of a PC connected to an active network . 19
Figure 2-4 — Relationship between End-to-End Delay and QoS Segment Delay . 57
Figure 2-5 — Relationship between QoS Segment Delay And MaxCommittedDelay. . 58
Figure 2-6 — Components of MaxCommittedDelay . 59
Figure 2-7 — Containers and How They Nest . 78
Figure A.1 — Example of a PC connected to an active network . 91

Table 2-1 — State Variables . 7
Table 2-2 — Reason Codes For AdmissionStatusNet . 24
Table 2-3 — Reason Codes For AdmissionStatusDev . 25
Table 2-4 — Containers In Which A Parameter Can Appear . 34
Table 2-5 — Reason Codes For A_ARG_TYPE_SetPreferredQphResults . 39
Table 2-6 — Event Moderat ion . 43
Table 2-7 — Actions . 45
Table 2-8 — Arguments for GetQosDeviceCapabilities() . 45
Table 2-9 — Error Codes for GetQosDeviceCapabilities() . 46
Table 2-10 — Arguments for GetQosState() . 46
Table 2-11 — Error Codes for GetQosState() . 47
Table 2-12 — Arguments for SetupTrafficQos() . 47
Table 2-13 — Error Codes for SetupTrafficQos() . 49
Table 2-14 — Arguments for ReleaseTrafficQos() . 49
Table 2-15 — Error Codes for ReleaseTrafficQos() . 50
Table 2-16 — Arguments for GetPathInformation() . 50
Table 2-17 — Error Codes for GetPathInformation . 50
Table 2-18 — Arguments for GetQosDeviceInfo() . 51
Table 2-19 — Error Codes for GetQosDeviceInfo() . 51
Table 2-20 — Arguments for ConfigureRotameterObservation() . 52
Table 2-21 — Error Codes for ConfigureRotameterObservation() . 53
Table 2-22 — Arguments for GetRotameterInformation() . 53
Table 2-23 — Error Codes for GetRotameterInformation() . 54
Table 2-24 — Arguments for AdmitTrafficQos() . 54
Table 2-25 — Error Codes for AdmitTrafficQos() . 61
Table 2-26 — Reason Codes for AdmitTrafficQos() . 61
Table 2-27 — Arguments for UpdateAdmittedQos() . 62

XXXX: © IEC:2010 — 4 — 29341-17-10 © ISO/IEC:2011(E)
Table 2-28 — Error Codes for UpdateAdmittedQos() . 65
Table 2-29 — Reason Codes for UpdateAdmittedQos() . 65
Table 2-30 — Arguments for ReleaseAdmittedQos() . 65
Table 2-31 — Error Codes for ReleaseAdmittedQos() . 67
Table 2-32 — Arguments for GetExtendedQosState() . 67
Table 2-33 — Error Codes for GetExtendedQosState() . 68
Table 2-34 — Arguments for SetPreferredQph() . 68
Table 2-35 — SetPreferredQphResults for SetPreferredQph() . 69
Table 2-36 — Arguments for GetUnexpectedStreamChanges() . 70
Table 2-37 — Error Codes for GetUnexpectedStreamChanges() . 70
Table 2-38 — Arguments for VerifyTrafficHandle() . 71
Table 2-39 — Error Codes for VerifyTrafficHandle() . 71
Table 2-40 — Arguments for UpdateTrafficLeaseTime() . 72
Table 2-41 — Error Codes for UpdateTrafficLeaseTime() . 72
Table 2-42 — Arguments for SetL2Map() . 73
Table 2-43 — Error Codes for SetL2Map() . 73
Table 2-44 — Error Code Summary . 73
Table 2-45 — Common Reason Codes . 75
Table 2-46 — Actions in Version 3 and Version 2 . 76
Table 2-47 — State Variables in Version 3 and Version 2 . 77
Table B.1 — Priority Mapping . 98
Table B.2 — Traffic Specification Parameters . 100
Table B.3 — ProtoTspec Parameters . 102
Table B.4 — AllocatedResources Parameters . 103

29341-17-10 © ISO/IEC:2011(E)
INFORMATION TECHNOLOGY –
UPNP DEVICE ARCHITECTURE –
Part 17-10: Quality of Service Device Control Protocol –
Level 3 – Quality of Service Device Service
FOREWORD
1) ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) form the
specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in
the development of International Standards. Their preparation is entrusted to technical committees; any ISO and
IEC member body interested in the subject dealt with may participate in this preparatory work. International
governmental and non-governmental organizations liaising with ISO and IEC also participate in this preparation.
2) In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
3) The formal decisions or agreements of IEC and ISO on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested IEC and ISO member bodies.
4) IEC, ISO and ISO/IEC publications have the form of recommendations for international use and are accepted
by IEC and ISO member bodies in that sense. While all reasonable efforts are made to ensure that the
technical content of IEC, ISO and ISO/IEC publications is accurate, IEC or ISO cannot be held responsible for
the way in which they are used or for any misinterpretation by any end user.
5) In order to promote international uniformity, IEC and ISO member bodies undertake to apply IEC, ISO and
ISO/IEC publications transparently to the maximum extent possible in their national and regional publications.
Any divergence between any ISO/IEC publication and the corresponding national or regional publication
should be clearly indicated in the latter.
6) ISO and IEC provide no marking procedure to indicate their approval and cannot be rendered responsible for
any equipment declared to be in conformity with an ISO/IEC publication.
7) All users should ensure that they have the latest edition of this publication.
8) No liability shall attach to IEC or ISO or its directors, employees, servants or agents including individual experts
and members of their technical committees and IEC or ISO member bodies for any personal injury, property
damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees)
and expenses arising out of the publication of, use of, or reliance upon, this ISO/IEC publication or any other IEC,
ISO or ISO/IEC publications.
9) Attention is drawn to the normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
10) Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
International Standard ISO/IEC 29341-17-10 was prepared by UPnP Forum Steering
committee , was adopted, under the fast track procedure, by subcommittee 25:
Interconnection of information technology equipment, of ISO/IEC joint technical committee 1:
Information technology.
The list of all currently available parts of the ISO/IEC 29341 series, under the general title
Information technology – UPnP device architecture, can be found on the IEC web site.
This International Standard has been approved by vote of the member bodies, and the voting
results may be obtained from the address given on the second title page.

—————————
rd
UPnP Forum Steering committee, UPnP Forum, 3855 SW 153 Drive, Beaverton, Oregon 97006 USA. See also
“Introduction”.
29341-17-10 © ISO/IEC:2011(E)
IMPORTANT – The “colour inside” logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this publication using a colour printer.

29341-17-10 XXXX: © IEC:2010 © ISO/IEC:2011(E) — 5 —
1 Overview and Scope
This service definition is compliant with the UPnP Device Architecture version 1.0.[DEVICE]
This service-type enables modeling of the ‘QosDevice’ function capabilities. The QosDevice:3
Service is a function typically implemented in source, sink and intermediate network. The
QosDevice Service is responsible for providing the appropriate network resources to traffic
streams and information about the state of the device as requested by the QosManager as
defined in the QosManager:3 Service. [QM]
Several L2 Technologies were considered during the design of UPnP-QoS v3. These
technologies are described in UPnP QosDevice:3 Underlying Technology Interface
Addendum [QD_Add] . Every attempt was made to ensure that the design of version 3 would
accommodate other L2 Technologies as well. Each L2 Technology on which UPnP-QoS
version 3 is implemented is recommended to have a document that is compliant to the
template in Annex B which specifies how the L2 Technology defines certain state variables,
maps parameters, etc.
This document does not address the procedures for end-to-end set up of a new traffic stream
or end-to-end revocation of an existing traffic stream. This procedure is defined in the UPnP
QosManager:3 Service Document [QM] .
1.1 Referenced Specifications
Unless explicitly stated otherwise herein, implementation of the mandatory provisions of any
standard referenced by this specification shall be mandatory for compliance with this
specification.
1.1.1 Normative References
This clause lists the normative references used in this document and includes the tag inside
square brackets that is used for each sub reference:
[Annex_G] – IEEE 802.1D-2004, Annex G, IEEE Standard for Information technology -
Telecommunications and information exchange between systems - IEEE standard for local
and metropolitan area networks - Common specifications - Media access control (MAC)
Bridges, 2004.
[XML] – Extensible Markup Language (XML) 1.0 (Second Edition), T. Bray, J. Paoli, C. M.
Sperberg-McQueen, E. Maler, eds. W3C Recommendations, 6 October 2000.
[QM] – UPnP QosManager:3 Service Document: This reference is informative except for the
definitions of the following state variables, which are normative:
A_ARG_TYPE_TrafficDescriptor, A_ARG_TYPE_NumTrafficDescriptors and
A_ARG_TYPE_TrafficHandle.
Available at: http://www.upnp.org/specs/qos/UPnP-qos-QosManager-v3-Service-
20081130.pdf
Latest version available at: http://www.upnp.org/specs/qos/UPnP-qos-QosManager-v3-
Service.pdf
[QPH] - UPnP QosPolicyHolder:3 Service Document
Available at: http://www.upnp.org/specs/qos/UPnP-qos-QosPolicyHolder-v3-Service-
20081130.pdf
Latest version available at: http://www.upnp.org/specs/qos/UPnP-qos-QosPolicyHolder-v3-
Service.pdf
[DEVICE] - UPnP Device Architecture, version 1.0.

XXXX: © IEC:2010 — 6 — 29341-17-10 © ISO/IEC:2011(E)
[RFC3339] – Date and Time on the Internet: Timestamps, G. Klyne, July 2002.
http://www.ietf.org/rfc/rfc3339.txt
[IANA] - IANA Interface Type (IANAifType)-MIB http://www.iana.org/assignments/ianaiftype-
mib
[QD_Add] –UPnP QosDevice:3 Underlying Technology Interface Addendum
Available at: http://www.upnp.org/specs/qos/UPnP-qos-QosDevice-v3-Addendum-
20081130.pdf
Latest version available at: http://www.upnp.org/specs/qos/UPnP-qos-QosDevice-v3-
Addendum.pdf
1.1.2 Informative References
This clause lists the informative references used in this document and includes the tag inside
square brackets that is used for each sub reference:
[QoS Architecture] – UPnP QoS Architecture V3.0
Available at: http://www.upnp.org/specs/qos/UPnP-qos-Architecture-v3-20081130.pdf
Latest version available at: http://www.upnp.org/specs/qos/UPnP-qos-Architecture-v3.pdf
[HomePlug AV] – HomePlug AV Specification, version 1.1.00, Homeplug Powerline Alliance,
www.HomePlug.org.
[MoCA1.0] MoCA MAC/PHY SPECIFICATION v1.0, 2006.
[MoCA1.1] MoCA MAC/PHY SPECIFICATION v1.1 EXTENSIONS. 2007.
[IEEE802.3] – IEEE Standard for Information technology— Telecommunications and
information exchange between systems—Local and metropolitan area networks—Specific
requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD)
access method and physical layer specifications IEEE Std 802.3™-2005.
http://standards.ieee.org/getieee802/802.3.html
[IEEE11] - 802.11-2007 IEEE Standard for Information Technology—Telecommunications and
information exchange between systems—Local and metropolitan area networks— Specific
requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications http://shop.ieee.org/ieeestore/Product.aspx?product_no=SS95708
[DSCP] - IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers, K. Nichols et al., December 1998.
Available at: http://www.ietf.org/rfc/rfc2474.txt
2 Service Modeling Definitions
2.1 ServiceType
The following service type identifies a service that is compliant with this template:

urn:schemas-upnp-org:service:QosDevice:3
The term QosDevice Service is used herein to refer to this type of service.

29341-17-10 XXXX: © IEC:2010 © ISO/IEC:2011(E) — 7 —
2.2 State Variables
Reader Note: For first-time reader, it may be more insightful to read the theory of
operations first and then the action definitions before reading the state variable
definitions.
2.2.1 XML Fragments as UPnP Arguments
UPnP-QoS often uses XML Fragments as arguments in UPnP actions. The containing UPnP
data type is a string. This places restrictions on a string’s content; it has to represent a well-
formed XML fragment (this includes a complete XML document).
An XML fragment, in adherence to the UPnP V1.0 architecture [DEVICE], MUST be escaped
by using the normal XML rules, [XML] Clause 2.4 Character Data and Markup, before
embedding it in a SOAP request / response message or an event notification message. The
XML escaping rules are summarized:
• The (<) character is encoded as (<)
• The (>) character is encoded as (>)
• The (&) character is encoded as (&)
• The (") character is encoded as (")
• The (') character is encoded as (')
In their XML fragments, implementations MAY use an explicit reference to appropriate
namespaces.
Table 2-1 — State Variables
Variable Name a Data Type Allowed Default Eng.
R/O
b b Units
Value Value
A_ARG_TYPE_TrafficDescriptor R String (XML See 2.2.2 n/a n/a
fragment)
A_ARG_TYPE_TrafficDescriptorContainer R String (XML See 2.2.31 n/a n/a
fragment)
A_ARG_TYPE_TrafficDescriptorsPerInterface R String (XML See 2.2.3 n/a n/a
fragment)
A_ARG_TYPE_TrafficHandle R string See 2.2.4 n/a n/a
A_ARG_TYPE_NumTrafficDescriptors R ui4 See 2.2.5 n/a n/a
A_ARG_TYPE_QosDeviceCapabilities R String (XML See 2.2.6 n/a n/a
fragment)
A_ARG_TYPE_QosDeviceState R String (XML See 2.2.7 n/a n/a
fragment)
PathInformation R String (XML See 2.2.8 n/a n/a
fragment)
A_ARG_TYPE_QosDeviceInfo R String (XML See 2.2.9 n/a n/a
fragment)
A_ARG_TYPE_QosDeviceInfoContainer R String (XML See 2.2.33 n/a n/a
fragment)
A_ARG_TYPE_QosStateId R string See 2.2.10 n/a n/a
A_ARG_TYPE_NumRotameterObservations O ui4 See 2.2.11 1 n/a
A_ARG_TYPE_RotameterInformation O String (XML See 2.2.12 n/a n/a
fragment)
A_ARG_TYPE_ConfRotameterObservations O String (XML See 2.2.13 n/a n/a
fragment)
XXXX: © IEC:2010 — 8 — 29341-17-10 © ISO/IEC:2011(E)

Variable Name a Data Type Allowed Default Eng.
R/O
b b Units
Value Value
MostRecentStreamAction O String (XML See 2.2.14 n/a n/a
fragment)
A_ARG_TYPE_MaxPossibleRotameterObservationO ui4 See 2.2.15 1 n/a
s
A_ARG_TYPE_Resource R String (XML See 2.2.16 n/a n/a
fragment)
A_ARG_TYPE_AdmitTrafficQosExtendedResult R String (XML See 2.2.17 n/a n/a
fragment)
A_ARG_TYPE_ListOfAdmittedTraffic R String (XML See 2.2.18 n/a n/a
fragment)
A_ARG_TYPE_PreferredQph O String (XML See 2.2.19 n/a n/a
fragment)
UnexpectedStreamChange R ui4 See 2.2.20 n/a n/a
A_ARG_TYPE_PreemptingTrafficInfo O String (XML See 2.2.21 n/a n/a
fragment)
A_ARG_TYPE_ListOfMostRecentUnexpectedStreaO String (XML See 2.2.22 n/a n/a
mChanges fragment)
A_ARG_TYPE_QosDeviceExtendedState R String (XML See 2.2.23 n/a n/a
fragment)
A_ARG_TYPE_Layer2Mapping R String (XML See 2.2.24 n/a n/a
fragment)
A_ARG_TYPE_Layer2MappingContainer R String (XML See 2.2.32 n/a n/a
fragment)
A_ARG_TYPE_AdmitTrafficQosSucceeded R boolean See 2.2.25 n/a n/a
A_ARG_TYPE_TrafficDescriptorsWanted R boolean See 2.2.26 n/a n/a
A_ARG_TYPE_SetPreferredQphResults O ui4 See 2.2.27 n/a n/a
A_ARG_TYPE_NumberOfUnexpectedStreamChan O ui4 See 2.2.28 n/a n/a
gesRequested
A_ARG_TYPE_NumberOfUnexpectedStreamChan O ui4 See 2.2.29 n/a n/a
gesReported
A_ARG_TYPE_NewTrafficLeaseTime R ui4 See 2.2.30 n/a n/a
a
R = Required, O = Optional, X = Non-standard
b
Values listed in this column are required. To specify standard optional values or to delegate assignment of

values to the vendor, you must reference a specific instance of an appropriate table below.
2.2.2 A_ARG_TYPE_TrafficDescriptor
This required state variable is defined in the QosManager Service specification; it contains
QoS related information for a traffic stream. Refer to [QM] for details of this state variable.
2.2.2.1 XML Schema Definition
This is a string containing an XML fragment. It contains information describing the traffic
descriptor. The XML fragment in this argument MUST validate against the XML schema for
TrafficDescriptor in the XML namespace
"http://www.upnp.org/schemas/TrafficDescriptorv1.xsd" which is located at
"http://www.upnp.org/schemas/qos/TrafficDescriptor-v3.xsd".
2.2.3 A_ARG_TYPE_TrafficDescriptorsPerInterface
This required state variable contains the list of traffic descriptors that are associated with a
network interface on a given QosDevice Service.

29341-17-10 XXXX: © IEC:2010 © ISO/IEC:2011(E) — 9 —
2.2.3.1 XML Schema Definition
This is a string containing an XML fragment. The XML fragment in this argument MUST
validate against the XML schema for TrafficDescriptorsPerInterface in the XML
namespace
"http://www.upnp.org/schemas/TrafficDescriptorsPerInterface.xsd" which is
located at
“http://www.upnp.org/schemas/qos/TrafficDescriptorsPerInterface-
v2.xsd”.
2.2.3.2 Description of fields in the TrafficDescriptorsPerInterface structure
The TrafficDescriptorsPerInterface is a structure that consists of one or more entries of
TdInterfacePair. TdInterfacePair lists one TrafficDescriptor, followed by the InterfaceId of the
associated interface. Here are the details about these two parameters:
: This required field describes a Traffic Descriptor associated with an
TrafficDescriptor
Interface. An Interface can have multiple associated Traffic Descriptor objects.
InterfaceId: This is a required field of type string; its format is defined in clause 2.2.6.2.
2.2.3.3 Sample argument XML string

xmlns="http://www.upnp.org:qos:tdpi2/schemas/TrafficDescriptorsPerInterface.xsd"
xmlns:td="http://www.upnp.org/schemas/TrafficDescriptorv1.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.upnp.org/schemas/TrafficDescriptorsPerInterface.xsd
http://www.upnp.org/schemas/qos/TrafficDescriptorsPerInterface-v2.xsd">


wxyz


192.168.1.50

23

192.168.1.50

23
1



300
AV


2
Audio


300
5

Amy's CP


eth0



XXXX: © IEC:2010 — 10 — 29341-17-10 © ISO/IEC:2011(E)
2.2.4 A_ARG_TYPE_TrafficHandle
A_ARG_TYPE_TrafficHandle is a string to identify a traffic stream. Refer to the [QM]
document for more details.
2.2.5 A_ARG_TYPE_NumTrafficDescriptors
This is an integer argument specifying the number of Traffic Descriptors contained in the
accompanying ListOfTrafficDescriptors. Refer to the [QM] document for more details.
2.2.6 A_ARG_TYPE_QosDeviceCapabilities
This required structure contains information describing a device’s QoS capabilities. Use of
this state variable is discouraged for UPnP-QoS v3. For v3 QosDevice Services, the
information contained in this state variable can also be found in the
A_ARG_TYPE_QosDeviceExtendedState state variable.
2.2.6.1 XML Schema Definition
This is a string containing an XML fragment. It contains information describing the
capabilities of the QosDevice Service. The XML fragment in this argument MUST validate
against the XML schema for QosDeviceCapabilities in the XML namespace
“http://www.upnp.org/schemas/QosDeviceCapabilities.xsd" which is located at
“http://www.upnp.org/schemas/qos/QosDeviceCapabilities-v2.xsd”.
2.2.6.2 Description of fields in the QosDeviceCapabilities structure
Interface: This is a required structure and defined as an XML element. This field describes
a network interface on the QosDevice Service. An Interface definition is required for each
interface supported by the device. This information is provided even if the physical interface
is down at a given time.
MacAddress: This is an optional field. If a given interface has an associated MAC address,
the QosDevice MUST provide this information here. It provides the MAC address of the
Interface and is of type MacAddressType (defined in the schema).
InterfaceId: This is a required field. The value is of type string and MUST uniquely identify
an interface within the QosDevice Service. Furthermore, the InterfaceId MUST remain the
same for a given interface (L2 Technology) until the QosDevice Service reboots.
IanaTechnologyType: This is an optional integer field. The IanaTechnologyType (IANA uses
the designation IANAifType) is an integer assigned by IANA for any media type, such as a
value of 6 for 802.3 media type or a value of 71 for 802.11 media type The allowed integer
values for this parameter are specified in [IANA].
AdmissionControlSupported: This is a required enumeration field. This field is maintained
for backward compatibility. This field can report only one of two values "Yes" or "No".
QosManager:3 ignores the value of this field.
PacketTaggingSupported: This is a required enumeration field. PacketTaggingSupported
field indicates whether the device is capable of tagging L2 priorities on the outgoing interface.
This field can report only one of two values "Yes" or "No".
NativeQos: This is an optional enumeration field. To ensure backward compatibility, this field
MUST contain one of the values (Prioritized, BestEffort).

29341-17-10 XXXX: © IEC:2010 © ISO/IEC:2011(E) — 11 —
MaxPhyRate: Indicates the maximum PHY rate of the interface and expressed as a value of
type unsignedInt. This parameter is required and indicates (Units) phy rate measured in
bits/sec.
ChannelInformation: This is an optional unsignedInt field . It indicates the channel number
of the IanaTechnologyType (IANAifType), if the technology supports channels. For example,
802.11 (value=71) supports multiple channels. Expressed as a value of type UnsignedInt.
2.2.6.3 Sample argument XML string

xmlns="http://www.upnp.org/schemas/QosDeviceCapabilities.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.upnp.org/schemas/QosDeviceCapabilities.xsd
http://www.upnp.org/schemas/qos/QosDeviceCapabilities-v2.xsd">

eth0
0212abcdef11
6
No
Yes
Prioritized
100000000


eth1
0212abcdef12
71
No
Yes
Prioritized
3000000

6



eth2
0212abcdef13
6
No
Yes
BestEffort
5000000


example1
0212abcdefff
12
No
Yes
BestEffort
5000000

6



2.2.7 A_ARG_TYPE_QosDeviceState
A_ARG_TYPE_QosDeviceState is a structure that provides information about a device’s
current QoS state. Use of this state variable is discouraged for UPnP-QoS v3.
2.2.7.1 XML Schema Definition
This is a string containing an XML fragment. It contains information describing the current
state of the QosDevice Service. The XML fragment in this argument MUST validate against

XXXX: © IEC:2010 — 12 — 29341-17-10 © ISO/IEC:2011(E)
the XML schema for QosDeviceState in the XML namespace
“http://www.upnp.org/schemas/QosDeviceState.xsd” which is located at
“http://www.upnp.org/schemas/qos/QosDeviceState-v2.xsd”.
2.2.7.2 Description of fields in the A_ARG_TYPE_QosDeviceState structure
QosStateId: This is a required string field. It MUST identify the QoS-related state of the
QosDevice Service. In particular it MUST change after successful invocations of
SetupTrafficQos() or ReleaseTrafficQos(). There may be other reasons a QosDevice Service
changes QosStateId, but when the QosStateId is the same at two instances in time, all
relevant QosDevice Service-state MUST be the same. Read the theory of operation for more
detail
...