ISO/IEC 29341-1:2008

ISO/IEC 29341-1
Edition 1.0 2008-11
INTERNATIONAL
STANDARD
Information technology – UPnP Device Architecture –
Part 1: UPnP Device Architecture Version 1.0

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-1
Edition 1.0 2008-11
INTERNATIONAL
STANDARD
Information technology – UPnP Device Architecture –
Part 1: UPnP Device Architecture Version 1.0

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
X
ICS 35.200 ISBN 978-2-88910-840-4

– 2 – 29341-1 © ISO/IEC:2008(E)
CONTENTS
FOREWORD . 4
ORIGINAL UPNP DOCUMENTS (informative). 6
Introduction. 8
What is UPnP Technology? .8
UPnP Forum.8
In this document .9
Audience .11
Required vs. recommended .11
Acronyms.11
References and resources .11
0. Addressing. 13
0.1 Addressing: Determining whether to use Auto-IP .13
0.2 Addressing: Choosing an address .13
0.3 Addressing: Testing the address.14
0.4 Addressing: Periodic checking for dynamic address availability.15
0.5 Addressing: Device naming and DNS interaction .15
0.6 Addressing: Name to IP address resolution.15
0.7 Addressing references .15
1. Discovery. 17
1.1 Discovery: Advertisement .19
1.2 Discovery: Search .24
1.3 Discovery references.27
2. Description . 28
2.1 Description: Device description.30
2.2 Description: UPnP Device Template.35
2.3 Description: Service description.35
2.4 Description: UPnP Service Template.40
2.5 Description: Non-standard vendor extensions .41
2.6 Description: UPnP Template Language for devices .42
2.7 Description: UPnP Template Language for services .45
2.8 Description: Retrieving a description.46
2.9 Description references .48
3. Control . 50
3.1 Control: Protocols.51
3.2 Control: Action.52
3.3 Control: Query for variable .59
3.4 Control references.63
4. Eventing. 65
4.1 Eventing: Subscription.67
4.2 Eventing: Event messages.73
4.3 Eventing: UPnP Template Language for eventing.76
4.4 Eventing: Augmenting the UPnP Template Language .76
4.5 Eventing references .77
5. Presentation. 78
5.1 Presentation references .79
Glossary . 80
Annex A (normative) IP Version 6 Support. 82
A.1 Introduction .82
A.2 General Principles.82
A.3 Addressing .84
A.4 Discovery .88
A.5 Description .91

29341-1 © ISO/IEC:2008(E) – 3 –
A.6 Control .91
A.7 Eventing .91
A.8 Presentation.91

– 4 – 29341-1 © ISO/IEC:2008(E)
INFORMATION TECHNOLOGY –
UPNP DEVICE ARCHITECTURE –
Part 1: UPnP Device Architecture Version 1.0
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.
IEC and ISO draw attention to the fact that it is claimed that compliance with this document may involve the use of
patents as indicated below.
ISO and IEC take no position concerning the evidence, validity and scope of the putative patent rights. The holders
of the putative patent rights have assured IEC and ISO that they are willing to negotiate free licences or licences
under reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect,
the statements of the holders of the putative patent rights are registered with IEC and ISO.
Intel Corporation has informed IEC and ISO that it has patent applications or granted patents.
Information may be obtained from:
Intel Corporation
Standards Licensing Department
5200 NE Elam Young Parkway
MS: JFS-98
USA – Hillsboro, Oregon 97124
Microsoft Corporation has informed IEC and ISO that it has patent applications or granted patents as listed below:
6101499 / US; 6687755 / US; 6910068 / US; 7130895 / US; 6725281 / US; 7089307 / US; 7069312 / US;
10/783 524 /US
29341-1 © ISO/IEC:2008(E) – 5 –
Information may be obtained from:
Microsoft Corporation
One Microsoft Way
USA – Redmond WA 98052
Philips International B.V. has informed IEC and ISO that it has patent applications or granted patents.
Information may be obtained from:
Philips International B.V. – IP&S
High Tech campus, building 44 3A21
NL – 5656 Eindhoven
NXP B.V. (NL) has informed IEC and ISO that it has patent applications or granted patents.
Information may be obtained from:
NXP B.V. (NL)
High Tech campus 60
NL – 5656 AG Eindhoven
Matsushita Electric Industrial Co. Ltd. has informed IEC and ISO that it has patent applications or granted patents.
Information may be obtained from:
Matsushita Electric Industrial Co. Ltd.
1-3-7 Shiromi, Chuoh-ku
JP – Osaka 540-6139
Hewlett Packard Company has informed IEC and ISO that it has patent applications or granted patents as listed
below:
5 956 487 / US; 6 170 007 / US; 6 139 177 / US; 6 529 936 / US; 6 470 339 / US; 6 571 388 / US; 6 205
466 / US
Information may be obtained from:
Hewlett Packard Company
1501 Page Mill Road
USA – Palo Alto, CA 94304
Samsung Electronics Co. Ltd. has informed IEC and ISO that it has patent applications or granted patents.
Information may be obtained from:
Digital Media Business, Samsung Electronics Co. Ltd.
416 Maetan-3 Dong, Yeongtang-Gu,
KR – Suwon City 443-742
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights
other than those identified above. IEC and ISO shall not be held responsible for identifying any or all such patent
rights.
ISO/IEC 29341-1 was prepared by UPnP Implementers Corporation and adopted, under the PAS procedure, by
joint technical committee ISO/IEC JTC 1, Information technology, in parallel with its approval by national bodies of
ISO and IEC.
The list of all currently available parts of the ISO/IEC 29341 series, under the general title Universal plug and play
(UPnP) 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.

– 6 – 29341-1 © ISO/IEC:2008(E)
ORIGINAL UPNP DOCUMENTS
(informative)
Reference may be made in this document to original UPnP documents. These references are retained in order to
maintain consistency between the specifications as published by ISO/IEC and by UPnP Implementers Corporation.
The following table indicates the original UPnP document titles and the corresponding part of ISO/IEC 29341:
UPnP Document Title ISO/IEC 29341 Part
UPnP Device Architecture 1.0 ISO/IEC 29341-1
UPnP Basic:1 Device ISO/IEC 29341-2
UPnP AV Architecture:1 ISO/IEC 29341-3-1
UPnP MediaRenderer:1 Device ISO/IEC 29341-3-2
UPnP MediaServer:1 Device ISO/IEC 29341-3-3
UPnP AVTransport:1 Service ISO/IEC 29341-3-10
UPnP ConnectionManager:1 Service ISO/IEC 29341-3-11
UPnP ContentDirectory:1 Service ISO/IEC 29341-3-12
UPnP RenderingControl:1 Service ISO/IEC 29341-3-13
UPnP MediaRenderer:2 Device ISO/IEC 29341-4-2
UPnP MediaServer:2 Device ISO/IEC 29341-4-3
UPnP AV Datastructure Template:1 ISO/IEC 29341-4-4
UPnP AVTransport:2 Service ISO/IEC 29341-4-10
UPnP ConnectionManager:2 Service ISO/IEC 29341-4-11
UPnP ContentDirectory:2 Service ISO/IEC 29341-4-12
UPnP RenderingControl:2 Service ISO/IEC 29341-4-13
UPnP ScheduledRecording:1 ISO/IEC 29341-4-14
UPnP DigitalSecurityCamera:1 Device ISO/IEC 29341-5-1
UPnP DigitalSecurityCameraMotionImage:1 Service ISO/IEC 29341-5-10
UPnP DigitalSecurityCameraSettings:1 Service ISO/IEC 29341-5-11
UPnP DigitalSecurityCameraStillImage:1 Service ISO/IEC 29341-5-12
UPnP HVAC_System:1 Device ISO/IEC 29341-6-1
UPnP HVAC_ZoneThermostat:1 Device ISO/IEC 29341-6-2
UPnP ControlValve:1 Service ISO/IEC 29341-6-10
UPnP HVAC_FanOperatingMode:1 Service ISO/IEC 29341-6-11
UPnP FanSpeed:1 Service ISO/IEC 29341-6-12
UPnP HouseStatus:1 Service ISO/IEC 29341-6-13
UPnP HVAC_SetpointSchedule:1 Service ISO/IEC 29341-6-14
UPnP TemperatureSensor:1 Service ISO/IEC 29341-6-15
UPnP TemperatureSetpoint:1 Service ISO/IEC 29341-6-16
UPnP HVAC_UserOperatingMode:1 Service ISO/IEC 29341-6-17
UPnP BinaryLight:1 Device ISO/IEC 29341-7-1
UPnP DimmableLight:1 Device ISO/IEC 29341-7-2
UPnP Dimming:1 Service ISO/IEC 29341-7-10
UPnP SwitchPower:1 Service ISO/IEC 29341-7-11
UPnP InternetGatewayDevice:1 Device ISO/IEC 29341-8-1
UPnP LANDevice:1 Device ISO/IEC 29341-8-2
UPnP WANDevice:1 Device ISO/IEC 29341-8-3
UPnP WANConnectionDevice:1 Device ISO/IEC 29341-8-4
UPnP WLANAccessPointDevice:1 Device ISO/IEC 29341-8-5
UPnP LANHostConfigManagement:1 Service ISO/IEC 29341-8-10
UPnP Layer3Forwarding:1 Service ISO/IEC 29341-8-11
UPnP LinkAuthentication:1 Service ISO/IEC 29341-8-12
UPnP RadiusClient:1 Service ISO/IEC 29341-8-13
UPnP WANCableLinkConfig:1 Service ISO/IEC 29341-8-14
UPnP WANCommonInterfaceConfig:1 Service ISO/IEC 29341-8-15
UPnP WANDSLLinkConfig:1 Service ISO/IEC 29341-8-16
UPnP WANEthernetLinkConfig:1 Service ISO/IEC 29341-8-17
UPnP WANIPConnection:1 Service ISO/IEC 29341-8-18
UPnP WANPOTSLinkConfig:1 Service ISO/IEC 29341-8-19
UPnP WANPPPConnection:1 Service ISO/IEC 29341-8-20
UPnP WLANConfiguration:1 Service ISO/IEC 29341-8-21
UPnP Printer:1 Device ISO/IEC 29341-9-1
UPnP Scanner:1.0 Device ISO/IEC 29341-9-2
UPnP ExternalActivity:1 Service ISO/IEC 29341-9-10
UPnP Feeder:1.0 Service ISO/IEC 29341-9-11
UPnP PrintBasic:1 Service ISO/IEC 29341-9-12
UPnP Scan:1 Service ISO/IEC 29341-9-13
UPnP QoS Architecture:1.0 ISO/IEC 29341-10-1
UPnP QosDevice:1 Service ISO/IEC 29341-10-10
UPnP QosManager:1 Service ISO/IEC 29341-10-11
UPnP QosPolicyHolder:1 Service ISO/IEC 29341-10-12
UPnP QoS Architecture:2 ISO/IEC 29341-11-1
UPnP QOS v2 Schema Files ISO/IEC 29341-11-2
UPnP QosDevice:2 Service ISO/IEC 29341-11-10

29341-1 © ISO/IEC:2008(E) – 7 –
UPnP Document Title ISO/IEC 29341 Part
UPnP QosManager:2 Service ISO/IEC 29341-11-11
UPnP QosPolicyHolder:2 Service ISO/IEC 29341-11-12
UPnP RemoteUIClientDevice:1 Device ISO/IEC 29341-12-1
UPnP RemoteUIServerDevice:1 Device ISO/IEC 29341-12-2
UPnP RemoteUIClient:1 Service ISO/IEC 29341-12-10
UPnP RemoteUIServer:1 Service ISO/IEC 29341-12-11
UPnP DeviceSecurity:1 Service ISO/IEC 29341-13-10
UPnP SecurityConsole:1 Service ISO/IEC 29341-13-11

– 8 – 29341-1 © ISO/IEC:2008(E)
Introduction
What is UPnP Technology?
UPnP technology defines an architecture for pervasive peer-to-peer network connectivity of intelligent appliances, wireless
devices, and PCs of all form factors. It is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or
unmanaged networks whether in the home, in a small business, public spaces, or attached to the Internet. UPnP technology
provides a distributed, open networking architecture that leverages TCP/IP and the Web technologies to enable seamless
proximity networking in addition to control and data transfer among networked devices.
The UPnP Device Architecture (UDA) is more than just a simple extension of the plug and play peripheral model. It is
designed to support zero-configuration, "invisible" networking, and automatic discovery for a breadth of device categories
from a wide range of vendors. This means a device can dynamically join a network, obtain an IP address, convey its
capabilities, and learn about the presence and capabilities of other devices. Finally, a device can leave a network smoothly
and automatically without leaving any unwanted state behind.
The technologies leveraged in the UPnP architecture include Internet protocols such as IP, TCP, UDP, HTTP, and XML. Like
the Internet, contracts are based on wire protocols that are declarative, expressed in XML, and communicated via HTTP.
Using internet protocols is a strong choice for UDA because of its proven ability to span different physical media, to enable
real world multiple-vendor interoperation, and to achieve synergy with the Internet and many home and office intranets. The
UPnP architecture has been explicitly designed to accommodate these environments. Further, via bridging, UDA
accommodates media running non-IP protocols when cost, technology, or legacy prevents the media or devices attached to it
from running IP.
What is "universal" about UPnP technology? No device drivers; common protocols are used instead. UPnP networking is media
independent. UPnP devices can be implemented using any programming language, and on any operating system. The UPnP
architecture does not specify or constrain the design of an API for applications; OS vendors may create APIs that suit their
customers’ needs.
UPnP Forum
The UPnP Forum is an industry initiative designed to enable easy and robust connectivity among stand-alone devices and PCs
from many different vendors. The UPnP Forum seeks to develop standards for describing device protocols and XML-based
device schemas for the purpose of enabling device-to-device interoperability in a scalable networked environment.
The UPnP Implementers Corporation (UIC) is comprised of UPnP Forum member companies across many industries who
promote the adoption of uniform technical device interconnectivity standards and testing and certifying of these devices.
The UIC develops and administers the testing and certification process, administers the UPnP logo program, and provides
information to UIC members and other interested parties regarding the certification of UPnP devices. The UPnP device
certification process is open to any vendor who is a member of the UPnP Forum and UIC, has paid the UIC dues, and has
devices that support UPnP functionality. For more information, see http://www.upnp-ic.org.

29341-1 © ISO/IEC:2008(E) – 9 –
The UPnP Forum has set up working committees in specific areas of domain expertise. These working committees are charged
with creating proposed device standards, building sample implementations, and building appropriate test suites. This
document indicates specific technical decisions that are the purview of UPnP Forum working committees.
UPnP vendors can build compliant devices with confidence of interoperability and benefits of shared intellectual property
and the logo program. Separate from the logo program, vendors may also build devices that adhere to the UPnP Device
Architecture defined herein without a formal standards procedure. If vendors build non-standard devices, they determine
technical decisions that would otherwise be determined by a UPnP Forum working committee.
In this document
The UPnP Device Architecture (formerly known as the DCP Framework) contained herein defines the protocols for
communication between controllers, or control points, and devices. For discovery, description, control, eventing, and
presentation, the UPnP Device Architecture uses the following protocol stack (the indicated colors and type styles are used
throughout this document to indicate where each protocol element is defined):
UPnP vendor [purple-italic]
UPnP Forum [red-italic]
UPnP Device Architecture [green-bold]
SSDP [blue] SOAP [blue] GENA [navy-bold]
HTTPMU (multicast) [black] HTTPU (unicast) [black] HTTP [black] HTTP [black]
UDP [black] TCP [black]
IP [black]
At the highest layer, messages logically contain only UPnP vendor-specific information about their devices. Moving down the
stack, vendor content is supplemented by information defined by UPnP Forum working committees. Messages from the layers
above are hosted in UPnP-specific protocols such as the Simple Service Discovery Protocol (SSDP) and the General Event
Notification Architecture (GENA) defined in this document, and others that are referenced. The above messages are
delivered via HTTP, either a multicast or unicast variety running over UDP, or the standard HTTP running over TCP.
Ultimately, all messages above are delivered over IP. The remaining sections of this document describe the content and
format for each of these protocol layers in detail. For reference, colors in [square brackets] above indicate which protocol
defines specific message components throughout this document.
Two general classifications of devices are defined by the UPnP architecture: controlled devices (or simply “devices”), and
control points. A controlled device functions in the role of a server, responding to requests from control points. Both control
points and controlled devices can be implemented on a variety of platforms including personal computers and embedded
systems. Multiple devices, control points, or both may be operational on the same network endpoint simultaneously.
The foundation for UPnP networking is IP addressing. Each device must have a Dynamic Host Configuration Protocol (DHCP)
client and search for a DHCP server when the device is first connected to the network. If a DHCP server is available, i.e., the
network is managed, the device must use the IP address assigned to it. If no DHCP server is available, i.e., the network is
unmanaged, the device must use Auto IP to get an address. In brief, Auto IP defines how a device intelligently chooses an IP
address from a set of reserved addresses and is able to move easily between managed and unmanaged networks. If during the

– 10 – 29341-1 © ISO/IEC:2008(E)
DHCP transaction, the device obtains a domain name, e.g., through a DNS server or via DNS forwarding, the device should use
that name in subsequent network operations; otherwise, the device should use its IP address.
Given an IP address, Step 1 in UPnP networking is discovery. When a device is added to the network, the UPnP discovery
protocol allows that device to advertise its services to control points on the network. Similarly, when a control point is added
to the network, the UPnP discovery protocol allows that control point to search for devices of interest on the network. The
fundamental exchange in both cases is a discovery message containing a few, essential specifics about the device or one of
its services, e.g., its type, identifier, and a pointer to more detailed information. The section on Discovery below explains
how devices advertise, how control points search, and details of the format of discovery messages.
Step 2 in UPnP networking is description. After a control point has discovered a device, the control point still knows very
little about the device. For the control point to learn more about the device and its capabilities, or to interact with the
device, the control point must retrieve the device's description from the URL provided by the device in the discovery message.
Devices may contain other, logical devices, as well as functional units, or services. The UPnP description for a device is
expressed in XML and includes vendor-specific, manufacturer information like the model name and number, serial number,
manufacturer name, URLs to vendor-specific Web sites, etc. The description also includes a list of any embedded devices or
services, as well as URLs for control, eventing, and presentation. For each service, the description includes a list of the
commands, or actions, the service responds to, and parameters, or arguments, for each action; the description for a service
also includes a list of variables; these variables model the state of the service at run time, and are described in terms of
their data type, range, and event characteristics. The section on Description below explains how devices are described and
how those descriptions are retrieved by control points.
Step 3 in UPnP networking is control. After a control point has retrieved a description of the device, the control point can
send actions to a device's service. To do this, a control point sends a suitable control message to the control URL for the
service (provided in the device description). Control messages are also expressed in XML using the Simple Object Access
Protocol (SOAP). Like function calls, in response to the control message, the service returns any action-specific values. The
effects of the action, if any, are modeled by changes in the variables that describe the run-time state of the service. The
section on Control below explains the description of actions, state variables, and the format of control messages.
Step 4 in UPnP networking is eventing. A UPnP description for a service includes a list of actions the service responds to and a
list of variables that model the state of the service at run time. The service publishes updates when these variables change,
and a control point may subscribe to receive this information. The service publishes updates by sending event messages.
Event messages contain the names of one of more state variables and the current value of those variables. These messages
are also expressed in XML. A special initial event message is sent when a control point first subscribes; this event message
contains the names and values for all evented variables and allows the subscriber to initialize its model of the state of the
service. To support scenarios with multiple control points, eventing is designed to keep all control points equally informed
about the effects of any action. Therefore, all subscribers are sent all event messages, subscribers receive event messages
for all evented variables that have changed, and event messages are sent no matter why the state variable changed (either in
response to a requested action or because the state the service is modeling changed). The section on Eventing below explains
subscription and the format of event messages.

29341-1 © ISO/IEC:2008(E) – 11 –
Step 5 in UPnP networking is presentation. If a device has a URL for presentation, then the control point can retrieve a page
from this URL, load the page into a browser, and depending on the capabilities of the page, allow a user to control the device
and/or view device status. The degree to which each of these can be accomplished depends on the specific capabilities of
the presentation page and device. The section on Presentation below explains the protocol for retrieving a presentation page.
Audience
The audience for this document includes UPnP device vendors, members of UPnP Forum working committees, and anyone
else who has a need to understanding the technical details of UPnP protocols.
This document assumes the reader is familiar with the HTTP, TCP, UDP, IP family of protocols; this document makes no
attempt to explain them. This document also assumes most readers will be new to XML, and while it is not an XML tutorial,
XML-related issues are addressed in detail given the centrality of XML to the UPnP device architecture. This document makes
no assumptions about the reader's understanding of various programming or scripting languages.
Required vs. recommended
In this document, features are described as Required, Recommended, or Optional as follows:
Required (or Must or Shall).
These basic features must be implemented to comply with the UPnP Device Architecture. The phrases “must not”
and “shall not” indicate behavior that is prohibited that if performed means the implementation is not in
compliance.
Recommended (or Should).
These features add functionality supported by the UPnP Device Architecture and should be implemented.
Recommended features take advantage of the capabilities of the UPnP Device Architecture, usually without
imposing major cost increases. Notice that for compliance testing, if a recommended feature is implemented, it
must meet the specified requirements to be in compliance with these guidelines. Some recommended features
could become requirements in the future. The phrase “should not” indicates behavior that is permitted but not
recommended.
Optional (or May).
These features are neither required nor recommended by the UPnP Device Architecture, but if the feature is
implemented, it must meet the specified requirements to be in compliance with these guidelines. These features
are not likely to become requirements in the future.
Acronyms
Acronym Meaning Acronym Meaning
ARP Address Resolution Protocol SOAP Simple Object Access Protocol
CP Control Point SSDP Simple Service Discovery Protocol
DCP Device Control Protocol UDA UPnP Device Architecture
DHCP Dynamic Host Configuration Protocol UPC Universal Product Code
DNS Domain Name System URI Uniform Resource Identifier
GENA General Event Notification Architecture URL Uniform Resource Locator
HTML HyperText Markup Language URN Uniform Resource Name
HTTP Hypertext Transfer Protocol UUID Universally Unique Identifier
HTTPMU HTTP (Multicast over UDP) XML Extensible Markup Language

HTTPU HTTP (Unicast over UDP)
References and resources
RFC 2616
HTTP: Hypertext Transfer Protocol 1.1. .
RFC 2279
UTF-8, a transformation format of ISO 10646 (character encoding). .
XML
– 12 – 29341-1 © ISO/IEC:2008(E)
Extensible Markup Language. W3C recommendation. .
Each section in this document contains additional information about resources for specific topics.

29341-1 © ISO/IEC:2008(E) – 13 –
0. Addressing
Addressing is Step 0 of UPnP networking. Through addressing, devices get a network address. Addressing enables discovery
(Step 1) where control points find interesting device(s), description (Step 2) where where control points learn about device
capabilities, control (Step 3) where a control point sends commands to device(s), eventing (Step 4) where control points
listen to state changes in device(s), and presentation (Step 5) where control points display a user interface for device(s).
The foundation for UPnP networking is IP addressing. Each UPnP device which does not itself implement a DHCP server must
have a Dynamic Host Configuration Protocol (DHCP) client and search for a DHCP server when the device is first connected to
the network (if the device itself implements a DHCP server, it may allocate itself an address from the pool that it controls). If
a DHCP server is available, i.e., the network is managed, the device must use the IP address assigned to it. If no DHCP server
is available, i.e., the network is unmanaged; the device must use automatic IP addressing (Auto-IP) to obtain an address.
Auto-IP as defined herein is how a device: (a) determines if DHCP is unavailable, and (b) intelligently chooses an IP address
from a set of link-local IP addresses. This method of address assignment enables a device to easily move between managed
and unmanaged networks.
This section provides a definition of the operation of Auto-IP. The operations described in this section are detailed and
clarified in the reference documents listed below. Where conflicts between this document and the reference documents
exist, the reference document always takes precedence.
0.1 Addressing: Determining whether to use Auto-IP
A device that supports Auto-IP and is configured for dynamic address assignment begins by requesting an IP address via DHCP
by sending out a DHCPDISCOVER message. The amount of time this DHCP Client should listen for DHCPOFFERs is
implementation dependent. If a DHCPOFFER is received during this time, the device must continue the process of dynamic
address assignment. If no valid DHCPOFFERs are received, the device may then auto-configure an IP address.
0.2 Addressing: Choosing an address
To auto-configure an IP address using Auto-IP, the device uses an implementation-dependent algorithm for choosing an
address in the 169.254/16 range. The first and last 256 addresses in this range are reserved and must not be used.
The selected address must then be tested to determine if the address is already in use. If the address is in use by another
device, another address must be chosen and tested, up to an implementation dependent number of retries. The address
selection should be randomized to avoid collision when multiple devices are attempting to allocate addresses. It is
recommended that the device choose an address using a pseudo-random algorithm (distributed over the entire address range
from 169.254.1.0 to 169.254.254.255) to minimize the likelihood that devices that join the network at the same time will
choose the same address and subsequently choose alternative addresses in the same sequence when collisions are detected.
This pseudo-random algorithm may be seeded using the device’s Ethernet hardware MAC address.

– 14 – 29341-1 © ISO/IEC:2008(E)
0.3 Addressing: Testing the address
To test the chosen address, the device must use an Address Resolution Protocol (ARP) probe. An ARP probe is an ARP request
with the device hardware address used as the sender's hardware address and the sender's IP address set to 0s. The device will
then listen for responses to the ARP probe, or other ARP probes for the same IP address. If either of these ARP packets is
seen, the device must consider the address in use and try a different address. The ARP probe may be repeated for greater
certainty that the address is not already in use; it is recommended that the probe be sent four times at two-second intervals.
After successfully configuring a link-local address, the device should send two gratuitous ARPs, spaced two seconds apart,
this time filling in the sender IP address. The purpose of these gratuitous ARPs is to make sure that other hosts on the net do
not have stale ARP cache entries left over from some other host that may previously have been using the same address.
Devices that are equipped with persistent storage may record the IP address they have selected and on the next boot use
that address as their first candidate when probing, in order to increase the stability of addresses and reduce the need to
resolve address conflicts.
Address collision detection should not be limited to the address testing phase, when the device is sending ARP probes and
listening for replies. Address collision detection is an ongoing process that is in effect for as long as the device is using a link-
local address. At any time, if a device receives an ARP packet with its own IP address given as the sender IP address, but a
sender hardware address that does not match its own hardware address, then the device should treat this as an address
collision and should respond as described in either (a) or (b) below:
(a) Immediately configure a new link-local IP address as described above; or,
(b) If the device currently has active TCP connections or other reasons to prefer to keep the same IP address, and has
not seen any other conflicting ARP packets recently (e.g., within the last ten seconds) then it may elect to attempt
to defend its address once, by recording the time that the conflicting ARP packet was received, and then
broadcasting one single gratuitous ARP, giving its own IP and hardware addresses as the source addresses of the
ARP. However, if another conflicting ARP packet is received within a short time after that (e.g., within ten
seconds) then the device should immediately configure a new Auto-IP address as described above.
The device should respond to conflicting ARP packets as described in either (a) or (b) above; it should not ignore conflicting
ARP packets. To switch over from one IP address to a new one, the device should, if possible, cancel any outstanding
advertisements made on the previous address, and must issue new advertisements on the new address. The section on
Discovery explains advertisements and their cancellations.
After successfully configuring an Auto-IP address, all subsequent ARP packets (replies as well as requests) containing an Auto-
IP source address should be sent using link-level broadcast instead of link-level unicast, in order to facilitate timely detection
of duplicate addresses. As an alternative, a device which cannot send broadcast ARP replies should send a unicast ARP reply
but then neglect to follow the instructions in RFC 826 about recording sender information from received ARP requests. This
means that, having failed to record the sender information, the device is likely to send a broadcast ARP request of its own
shortly later, which allows another device using the same IP address to detect the conflict and respond to it.

29341-1 © ISO/IEC:2008(E) – 15 –
IP packets whose source or destination addresses are in the 169.254/16 range must not be sent to any router for forwarding.
IP datagrams with a multicast destination address and an Auto-IP source address should not be forwarded off the local link.
Devices and control points may assume that all 169.254/16 destination addresses are on-link and directly reachable. The
169.254/16 address range MUST NOT be subnetted.
0.4 Addressing: Periodic checking for dynamic address availability
A device that has auto-configured an IP address must periodically check for the existence of a DHCP server. This is
accomplished by sending DHCPDISCOVER messages. How often this check is made is implementation dependent, but checking
every 5 minutes would maintain a balance between network bandwidth required and connectivity maintenance. If a
DHCPOFFER is received, the device must proceed with
...