Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-26-3: UPnP WANPotLinkConfig v1 — Potential Link Configuration for WAN Interfaces
Technical examination of the WANPotLinkConfig:1 service that manages potential WAN link parameters, including pre-connection configuration and link capability discovery.
Overview of WANPotLinkConfig:1
The ISO/IEC 29341-26-3 standard defines the WANPotLinkConfig:1 (WAN Potential Link Configuration) service, a specialised UPnP service that exposes the pre-connection configuration parameters and capabilities of a WAN physical interface. Unlike the WANCommonInterfaceConfig service, which reports the current operational state of an active link, WANPotLinkConfig focuses on the potential link characteristics — what the interface is capable of before a connection is established.
WANPotLinkConfig:1 is especially valuable for DSL and fibre modems where the physical layer can support multiple profiles or encapsulation modes. An engineer debugging a line synchronisation issue can use this service to query the attainable bit rate, signal-to-noise ratio (SNR) margin, and supported modulation schemes without needing to establish a full Layer 3 connection.
The service is identified by the service type URN urn:schemas-upnp-org:service:WANPotLinkConfig:1. It is typically embedded within the WANDevice root device alongside WANCommonInterfaceConfig. While optional in the baseline IGD specification, it is highly recommended for any gateway that supports multiple WAN link profiles or where the physical layer configuration is user-selectable.
Key State Variables and Actions
The WANPotLinkConfig:1 service defines a focused set of state variables that describe the potential capabilities of the WAN link before a connection is established. These variables are read-only in most implementations, though some allow configuration of the desired link profile.
| State Variable | Type | Description |
|---|---|---|
| PotentialDownlinkBitRate | ui4 (bps) | Maximum attainable downstream bit rate based on current line conditions |
| PotentialUplinkBitRate | ui4 (bps) | Maximum attainable upstream bit rate based on current line conditions |
| PotentialDownlinkMaxBitRate | ui4 (bps) | Theoretical maximum downstream bit rate supported by the hardware |
| PotentialUplinkMaxBitRate | ui4 (bps) | Theoretical maximum upstream bit rate supported by the hardware |
| LinkType | string | WAN physical medium type: “DSL”, “Cable”, “Ethernet”, “LTE”, “Fibre”, etc. |
| LinkConfiguration | string | Vendor-specific configuration descriptor (e.g., “G.993.2 VDSL2 Profile 17a”) |
The service exposes two primary actions: GetPotentialLinkConfig retrieves all potential link parameters in a single call, and GetPotentialLinkConfigParam retrieves a specific parameter by name. The eventing mechanism fires on changes to any of the potential bit rate variables, allowing control points to react to changes in line quality (e.g., due to crosstalk or temperature variation on a DSL line).
The
PotentialDownlinkBitRate and PotentialUplinkBitRate are calculated by the physical-layer modem firmware based on real-time line measurements. On DSL modems, these values can fluctuate significantly over a 24-hour period due to diurnal temperature changes affecting loop resistance. Implementations should update these variables at least once per minute, not just on initial training, to give control points an accurate picture of current line capacity.Engineering Applications and Integration Patterns
One of the primary use cases for WANPotLinkConfig:1 is in adaptive bandwidth management. A quality-of-service (QoS) engine can read the potential link bit rates to dynamically adjust traffic shaping policies. For example, if the potential downlink bit rate drops from 100 Mbps to 80 Mbps due to line degradation, the QoS engine can reduce its maximum bandwidth allocation to prevent bufferbloat and maintain low latency for interactive traffic.
Another important application is line diagnostics and troubleshooting. Field technicians and automated monitoring systems can use the WANPotLinkConfig service to assess line quality before attempting to establish a connection. If the potential downlink rate is significantly below the subscribed rate, the service indicates a physical-layer problem that requires investigation (e.g., a faulty splitter, excessive loop length, or crosstalk from adjacent pairs).
On VDSL2 and G.fast modems, the WANPotLinkConfig:1 service can expose advanced line metrics such as the attainable net data rate (including the impact of retransmission overhead), the supported vectoring profiles, and the estimated loop length. Engineers designing automated line qualification tools should combine data from WANPotLinkConfig with the physical-layer counters from WANCommonInterfaceConfig to build a comprehensive link health dashboard.
From a system integration perspective, the WANPotLinkConfig service is typically implemented in the modem HAL (Hardware Abstraction Layer) rather than in the UPnP daemon itself. The modem driver exposes the potential link parameters via an internal API (e.g., ioctl calls on Linux or vendor-specific DSL library functions), and the UPnP daemon periodically reads these values through well-defined interfaces. This separation of concerns ensures that the UPnP layer remains agnostic to the underlying WAN technology.
There is a critical timing consideration when reading potential link parameters during a line retrain. When a DSL modem is retraining (resynchronising with the DSLAM), the potential bit rate estimates can vary wildly as the modem explores different modulation and coding schemes. Implementations should debounce the state variable updates during retrain events and only publish stable values after the line has achieved showtime (full synchronisation). Publishing transient values can confuse control points and trigger unnecessary QoS adjustments.
When implementing WANPotLinkConfig on multi-WAN devices (e.g., a gateway with both DSL and LTE WAN interfaces), expose separate WANPotLinkConfig service instances within each WANConnectionDevice context. Alternatively, if a single WANDevice hosts multiple physical interfaces, a single WANPotLinkConfig service can expose the potential link parameters for the currently preferred interface, or the service can be extended with vendor-specific variables to enumerate all available interfaces.
Frequently Asked Questions
Q: What is the difference between WANPotLinkConfig and WANCommonInterfaceConfig?
A: WANCommonInterfaceConfig reports the operational status of an active link (e.g., current bit rate, bytes sent/received, link up/down state). WANPotLinkConfig reports the potential capabilities of the link before a connection is established (e.g., maximum attainable bit rate under current line conditions). Think of WANCommonInterfaceConfig as “what is happening now” and WANPotLinkConfig as “what the line is capable of.”
A: WANCommonInterfaceConfig reports the operational status of an active link (e.g., current bit rate, bytes sent/received, link up/down state). WANPotLinkConfig reports the potential capabilities of the link before a connection is established (e.g., maximum attainable bit rate under current line conditions). Think of WANCommonInterfaceConfig as “what is happening now” and WANPotLinkConfig as “what the line is capable of.”
Q: Can WANPotLinkConfig be used to configure the WAN link profile?
A: The base WANPotLinkConfig:1 service is read-only for potential link parameters. Some vendor extensions add actions like
A: The base WANPotLinkConfig:1 service is read-only for potential link parameters. Some vendor extensions add actions like
SetDesiredLinkProfile to select among supported profiles (e.g., selecting G.992.5 ADSL2+ vs. G.993.2 VDSL2), but this is not part of the standard. Configuration of active connection parameters is handled by the WANIPConnection or WANPPPConnection services.Q: Does WANPotLinkConfig apply to non-DSL WAN technologies?
A: Yes. While the service was originally conceived with DSL in mind, it applies to any WAN technology where the physical layer has configurable profiles or where the link capability differs from the subscribed rate. For cable modems, it can report the DOCSIS channel bonding capacity; for LTE, it can report the RSSI and RSRQ-based throughput estimates; for fibre (GPON/XGS-PON), it can report the optical power budget and supported line rates.
A: Yes. While the service was originally conceived with DSL in mind, it applies to any WAN technology where the physical layer has configurable profiles or where the link capability differs from the subscribed rate. For cable modems, it can report the DOCSIS channel bonding capacity; for LTE, it can report the RSSI and RSRQ-based throughput estimates; for fibre (GPON/XGS-PON), it can report the optical power budget and supported line rates.
