Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-10-10: UPnP QoS Device Service
Service-Level Interface for QoS Policy Configuration, Monitoring, and Bandwidth Reservation
1. QoS Device Service Service Architecture
ISO/IEC 29341-10-10 specifies the UPnP QoS Device Service, the service-level interface that exposes QoS Device capabilities to UPnP control points. This service defines the actions, state variables, and event mechanisms that enable control points to query, configure, and monitor QoS policies on a QoS-capable device. It is the programmatic interface through which the UPnP QoS framework achieves traffic management.
The QoS Device Service operates as a standard UPnP service hosted on the QoS Device. It exposes actions for retrieving supported traffic classes, applying traffic policies, querying current QoS state, and subscribing to QoS-related events such as bandwidth changes or policy violations.
When implementing the QoS Device Service, design your state variable table to minimize evented variables. Only mark variables as evented if control points genuinely need real-time notifications — excessive eventing generates unnecessary network traffic and increases control point processing overhead.
2. Key Actions and State Variables
The QoS Device Service defines a comprehensive set of actions organized into functional groups. Configuration actions allow control points to set traffic policies and bandwidth reservations. Query actions retrieve current QoS state, active flow information, and available traffic classes. Monitoring actions provide access to QoS statistics including packet counts, dropped packets, and queue depths.
State variables in the QoS Device Service are categorized into configuration variables (writeable by authorized control points), status variables (read-only, reflecting current device state), and evented variables (triggering notifications on change). Critical state variables include: QosDeviceState (idle/active/configuring/error), TotalBandwidth, AvailableBandwidth, ActiveFlowCount, and PolicyViolationCount.
| Action Name | Category | Description | Key Arguments |
|---|---|---|---|
| GetSupportedTrafficClasses | Query | Retrieves list of supported traffic classes | Out: TrafficClassList |
| ApplyTrafficPolicy | Configuration | Applies a QoS policy to a traffic flow | In: FlowSpec, TrafficClass, Priority |
| RemoveTrafficPolicy | Configuration | Removes a previously applied policy | In: PolicyID |
| GetQosState | Query | Retrieves current QoS device state | Out: QosState, ActiveFlows |
| GetQosStatistics | Query | Gets traffic/performance statistics | Out: StatsData |
| RequestBandwidthReservation | Configuration | Reserves bandwidth for a specific flow | In: FlowID, Bandwidth, Duration |
| ReleaseBandwidthReservation | Configuration | Releases a bandwidth reservation | In: ReservationID |
| SubscribeToQosEvents | Eventing | Subscribes to QoS event notifications | In: EventFilter, Out: SubscriptionID |
The ApplyTrafficPolicy action must validate that the requested traffic class is compatible with the device’s capabilities. Returning an overly generic error (e.g., “Action failed”) when a specific traffic class is unsupported makes debugging difficult for control point developers.
3. Implementing the QoS Device Service in Practice
Practical implementation of the QoS Device Service requires careful thread safety design. The service must handle concurrent action invocations from multiple control points while maintaining consistency of state variables. The standard recommends using a reader-writer lock pattern: multiple simultaneous query actions are safe, but configuration actions should acquire exclusive access to prevent race conditions.
Error handling deserves special attention. The service should return meaningful error codes for common failure scenarios: 402 (Invalid Args) for malformed action parameters, 501 (Action Failed) for internal device errors, 606 (Argument Value Out of Range) for invalid traffic class or bandwidth values, and 702 (Not Authorized) when the requesting control point lacks permission.
For bandwidth reservation management, implement a timeout mechanism that automatically releases orphaned reservations when a control point disconnects unexpectedly. The standard suggests a configurable timeout, with 300 seconds (5 minutes) as a reasonable default. This prevents bandwidth from being permanently consumed by crashed or unresponsive control points.
A well-implemented QoS Device Service with proper error handling and timeout mechanisms can maintain stable QoS guarantees even during control point failures, automatically recovering bandwidth reservations within the configured timeout period.
Never implement the QoS Device Service with blocking action handlers. A slow or blocked action (e.g., querying hardware QoS registers that are temporarily busy) will stall the entire service, preventing other control points from retrieving QoS state or applying policies.
4. Frequently Asked Questions
Q: How many concurrent QoS policies can a QoS Device Service manage?
A: This is implementation-dependent and primarily limited by the device’s memory and hardware QoS table size. Consumer-grade devices typically support 8-32 concurrent policies, while enterprise equipment can handle hundreds or thousands.
A: This is implementation-dependent and primarily limited by the device’s memory and hardware QoS table size. Consumer-grade devices typically support 8-32 concurrent policies, while enterprise equipment can handle hundreds or thousands.
Q: Does the QoS Device Service persist policies across device reboots?
A: Persistence is optional. The standard defines a PersistPolicy action flag — when set, the device stores the policy in non-volatile memory. However, most consumer implementations default to volatile (non-persistent) policies that are cleared on reboot.
A: Persistence is optional. The standard defines a PersistPolicy action flag — when set, the device stores the policy in non-volatile memory. However, most consumer implementations default to volatile (non-persistent) policies that are cleared on reboot.
Q: How does the service handle conflicting policy requests from multiple control points?
A: The standard defines a priority-based resolution scheme. Each ApplyTrafficPolicy request includes a priority parameter. When conflicts arise, the policy with the highest priority takes effect, and the lower-priority control point receives an event notification about the override.
A: The standard defines a priority-based resolution scheme. Each ApplyTrafficPolicy request includes a priority parameter. When conflicts arise, the policy with the highest priority takes effect, and the lower-priority control point receives an event notification about the override.
Q: What transport protocols are supported for QoS signaling between the service and network elements?
A: The service communicates with upstream network elements through an abstraction layer. Common protocols include SNMP (for managed switches), 802.1p tagging (for VLAN-capable switches), and DiffServ DSCP marking (for IP routers). The specific mechanism depends on the network element capabilities.
A: The service communicates with upstream network elements through an abstraction layer. Common protocols include SNMP (for managed switches), 802.1p tagging (for VLAN-capable switches), and DiffServ DSCP marking (for IP routers). The specific mechanism depends on the network element capabilities.
