Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-1-1: UPnP Device Architecture v1.0
Foundational UPnP Protocol Stack, Device Description, and Service Control
1. UPnP Device Architecture Version 1.0
ISO/IEC 29341-1-1 defines the foundational UPnP Device Architecture Version 1.0, the initial standardized release of the UPnP protocol suite. This version establishes the baseline protocols and device interaction models that all subsequent UPnP standards extend and refine. As the cornerstone of the 29341 series, it specifies the mandatory behaviors for both devices and control points.
Version 1.0 introduced the six-layer protocol stack that remains the backbone of UPnP today: addressing via DHCP/Auto-IP, discovery through SSDP, device and service description retrieval using XML, SOAP-based control, GENA eventing, and optional presentation pages. This architecture was revolutionary at its time for bringing zero-configuration networking to consumer electronics.
When building v1.0-compliant devices, remember that SSDP advertisements must include a CACHE-CONTROL header with a max-age directive (minimum 1800 seconds by convention) so that control points can manage device presence timeouts correctly.
2. Device and Service Description Model
The description model in version 1.0 uses XML schemas to define device and service capabilities. The device description document (retrieved via the URL embedded in the SSDP LOCATION header) contains manufacturer metadata, model information, and links to service description documents.
Each service description document defines: a list of actions (methods that control points can invoke), state variables (typed data that reflects the device’s runtime state), and service control protocol definitions. State variables can be evented (sending notifications on change) or non-evented. The data types supported include Boolean, numeric types (i1, ui1, i2, ui2, i4, ui4, int, r4, r8, number), string, date/time types, and binary data (bin.base64, bin.hex).
| State Variable Type | Description | Usage Example |
|---|---|---|
| Boolean | True/False flag | PowerStatus, ConnectionState |
| ui1 | Unsigned 8-bit integer (0-255) | VolumeLevel, ChannelNumber |
| i4 | Signed 32-bit integer | ErrorCode, TimeRemaining |
| string | UTF-8 encoded text | DeviceName, FriendlyName |
| r4 | 32-bit floating point | Temperature, Position |
| bin.base64 | Base64-encoded binary | FirmwareImage, IconData |
| dateTime | ISO 8601 date/time | LastUpdate, AlarmTime |
| uri | Uniform Resource Identifier | DeviceURL, IconURL |
Version 1.0 does not define mandatory security mechanisms. All SOAP action invocations are sent as plain HTTP POST requests. In production environments, always combine UPnP with network-layer security (VLAN segmentation, firewall rules) to mitigate unauthorized access risks.
3. Engineering Practices for Reliable UPnP v1.0 Deployments
Field experience with UPnP v1.0 has revealed several engineering best practices. First, control points must implement robust timeout handling — SSDP M-SEARCH responses can be delayed, and devices may become unresponsive without sending an SSDP byebye message. Second, the XML parser in the device should be resistant to malformed SOAP requests that could crash the device stack.
For multicast stability, the standard recommends that SSDP NOTIFY messages be sent with a random jitter of up to 100 milliseconds to avoid network storms when many devices power on simultaneously (a common scenario after a power outage). Similarly, M-SEARCH responses should include a random delay between 0 and the Advertisement Age specified in the device’s CACHE-CONTROL header.
Devices that correctly implement the v1.0 discovery jitter mechanism show significantly lower network packet loss rates during mass power-on events compared to devices that transmit all advertisements simultaneously.
A common v1.0 implementation pitfall is embedding full device descriptions directly in SSDP packets. The LOCATION header should contain a URL pointing to the XML description, not the XML itself — embedding descriptions causes UDP packet fragmentation and unreliable discovery.
4. Frequently Asked Questions
Q: What is the maximum SSDP packet size for v1.0?
A: SSDP messages use UDP and should ideally fit within a single Ethernet frame (1500 bytes MTU). In practice, SSDP NOTIFY and M-SEARCH packets should not exceed 1500 bytes to avoid IP fragmentation, which is unreliable over UDP.
A: SSDP messages use UDP and should ideally fit within a single Ethernet frame (1500 bytes MTU). In practice, SSDP NOTIFY and M-SEARCH packets should not exceed 1500 bytes to avoid IP fragmentation, which is unreliable over UDP.
Q: Can a UPnP v1.0 device have multiple services?
A: Yes, a single device can host multiple services, each with its own service description document. The device description document lists all available services with their corresponding control, event subscription, and description URLs.
A: Yes, a single device can host multiple services, each with its own service description document. The device description document lists all available services with their corresponding control, event subscription, and description URLs.
Q: How does a control point discover device departure?
A: Two mechanisms are available: (1) the device sends an SSDP NOTIFY with NTS = ssdp:byebye before shutting down, and (2) the control point detects timeout when the device’s advertisement expires (based on CACHE-CONTROL max-age). Reliable implementations use both.
A: Two mechanisms are available: (1) the device sends an SSDP NOTIFY with NTS = ssdp:byebye before shutting down, and (2) the control point detects timeout when the device’s advertisement expires (based on CACHE-CONTROL max-age). Reliable implementations use both.
