Broadband Forum

    DATA MODEL DEFINITION


Component objects for CWMP: TR-069 Device:1.4 and
InternetGatewayDevice:1.6 Root Object definitions
tr-157-1-1-0.xml

License

Copyright (c) 2009-2017, Broadband Forum

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The above license is used as a license under copyright only. Please reference the Forum IPR Policy for patent licensing terms <https://www.broadband-forum.org/ipr-policy>.

Any moral rights which are necessary to exercise under the above license grant are also deemed granted under this license.

Table of Contents

Data Types

The Parameters defined in this specification make use of a limited subset of the default SOAP data types [SOAP1.1]. These data types and the named data types used by this specification are described below.

Note: A Parameter that is defined to be one of the named data types is reported as such at the beginning of the Parameter's description via a reference back to the associated data type definition (e.g. [MacAddress]). However, such parameters still indicate their SOAP data type.

Data Type Base Type Description
Alias string(64)

A non-volatile handle used to reference this instance. Alias provides a mechanism for an ACS to label this instance for future reference.

If the CPE supports the Alias-based Addressing feature as defined in [Section 3.6.1/TR-069a4] and described in [Appendix II/TR-069a4], the following mandatory constraints MUST be enforced:

  • Its value MUST NOT be empty.
  • Its value MUST start with a letter.
  • If its value is not assigned by the ACS, it MUST start with a "cpe-" prefix.
  • The CPE MUST NOT change the parameter value.
Dbm1000 int The value is measured in dBm/1000, i.e. the value divided by 1000 is dB relative to 1 mW. For example, -12345 means -12.345 dBm, 0 means 0 dBm (1 mW) and 12345 means 12.345 dBm.
IEEE_EUI64 string(23)

The IEEE EUI 64-bit identifier as defined in [EUI64]. The IEEE defined 64-bit extended unique identifier (EUI-64) is a concatenation of:

  • The 24-bit (OUI-24) or 36-bit (OUI-36) company_id value assigned by the IEEE Registration Authority (IEEE-RA), and
  • The extension identifier (40 bits for OUI-24 or 28 bits for OUI-36) assigned by the organization with that company_id assignment.

Possible patterns:

  • <Empty> (an empty string)
  • ([0-9A-Fa-f][0-9A-Fa-f]:){7}([0-9A-Fa-f][0-9A-Fa-f])
IPAddress string(45)

IP address, i.e. IPv4 address (or IPv4 subnet mask) or IPv6 address.

All IPv4 addresses and subnet masks MUST be represented as strings in IPv4 dotted-decimal notation. Here are some examples of valid IPv4 address textual representations:

  • 216.52.29.100
  • 192.168.1.254

All IPv6 addresses MUST be represented using any of the 3 standard textual representations defined in [RFC4291] Sections 2.2.1, 2.2.2 and 2.2.3. Both lower-case and upper-case letters can be used, but use of lower-case letters is RECOMMENDED. Here are some examples of valid IPv6 address textual representations:

  • 1080:0:0:800:ba98:3210:11aa:12dd
  • 1080::800:ba98:3210:11aa:12dd
  • 0:0:0:0:0:0:13.1.68.3

IPv6 addresses MUST NOT include zone identifiers. Zone identifiers are discussed in [Section 6/RFC4007].

Unspecified or inapplicable addresses (or IPv4 subnet masks) MUST be represented as empty strings unless otherwise specified by the parameter definition.

IPPrefix string(49)

IPv4 or IPv6 routing prefix in Classless Inter-Domain Routing (CIDR) notation [RFC4632]. This is specified as an IP address followed by an appended "/n" suffix, where n (the prefix size) is an integer in the range 0-32 (for IPv4) or 0-128 (for IPv6) that indicates the number of (leftmost) '1' bits of the routing prefix.

  • IPv4 example: 192.168.1.0/24
  • IPv6 example: 2001:edff:fe6a:f76::/64

If the IP address part is unspecified or inapplicable, it MUST be an empty string unless otherwise specified by the parameter definition. In this case the IP prefix will be of the form "/n".

If the entire IP prefix is unspecified or inapplicable, it MUST be an empty string unless otherwise specified by the parameter definition.

IPv4Address IPAddress(15)

IPv4 address (or subnet mask).

Can be any IPv4 address that is permitted by the IPAddress data type.

IPv4Prefix IPPrefix(18)

IPv4 address prefix.

Can be any IPv4 prefix that is permitted by the IPPrefix data type.

IPv6Address IPAddress(45)

IPv6 address.

Can be any IPv6 address that is permitted by the IPAddress data type.

IPv6Prefix IPPrefix(49)

IPv6 address prefix.

Can be any IPv6 prefix that is permitted by the IPPrefix data type.

MACAddress string(17)

All MAC addresses are represented as strings of 12 hexadecimal digits (digits 0-9, letters A-F or a-f) displayed as six pairs of digits separated by colons. Unspecified or inapplicable MAC addresses MUST be represented as empty strings unless otherwise specified by the parameter definition. Possible patterns:

  • <Empty> (an empty string)
  • ([0-9A-Fa-f][0-9A-Fa-f]:){5}([0-9A-Fa-f][0-9A-Fa-f])
StatsCounter32 unsignedInt

A 32-bit statistics parameter, e.g. a byte counter.

This data type SHOULD NOT be used for statistics parameters whose values might become greater than the maximum value that can be represented as an unsignedInt (i.e. 0xffffffff, referred to below as maxval). StatsCounter64 SHOULD be used for such parameters.

The value maxval indicates that no data is available for this parameter. In the unlikely event that the actual value of the statistic is maxval, the CPE SHOULD return maxval - 1.

The actual value of the statistic might be greater than maxval. Such values SHOULD wrap around through zero.

The term packet is to be interpreted as the transmission unit appropriate to the protocol layer in question, e.g. an IP packet or an Ethernet frame.

StatsCounter64 unsignedLong

A 64-bit statistics parameter, e.g. a byte counter.

This data type SHOULD be used for all statistics parameters whose values might become greater than the maximum value that can be represented as an unsignedInt.

The maximum value that can be represented as an unsignedLong (i.e. 0xffffffffffffffff) indicates that no data is available for this parameter.

The term packet is to be interpreted as the transmission unit appropriate to the protocol layer in question, e.g. an IP packet or an Ethernet frame.

UUID string(36:36)

Universally Unique Identifier. See [RFC4122]. Possible patterns:

  • [A-Fa-f0-9]{8}-[A-Fa-f0-9]{4}-[A-Fa-f0-9]{4}-[A-Fa-f0-9]{4}-[A-Fa-f0-9]{12}
ZigBeeNetworkAddress string(4)

The ZigBee 16-bit network address (NWK) as defined in [ZigBee2007]. The address is assigned to a device by the network layer and used by the network layer for routing messages between devices. Possible patterns:

  • <Empty> (an empty string)
  • ([0-9A-Fa-f]){4}
base64 -

Base64 encoded binary (no line-length limitation).

A minimum and maximum allowed length can be indicated using the form base64(Min:Max), where Min and Max are the minimum and maximum length in characters before Base64 encoding. If either Min or Max are missing, this indicates no limit, and if Min is missing the colon can also be omitted, as in base64(Max). Multiple comma-separated ranges can be specified, in which case the length MUST be in one of the ranges.

boolean - Boolean, where the allowed values are 0 or 1 (or equivalently, true or false).
dateTime - The subset of the ISO 8601 date-time format defined by the SOAP dateTime type.
hexBinary -

Hex encoded binary.

A minimum and maximum allowed length can be indicated using the form hexBinary(Min:Max), where Min and Max are the minimum and maximum length in characters before Hex Binary encoding. If either Min or Max are missing, this indicates no limit, and if Min is missing the colon can also be omitted, as in hexBinary(Max). Multiple comma-separated ranges can be specified, in which case the length MUST be in one of the ranges.

int -

Integer in the range -2147483648 to +2147483647, inclusive.

For some int types, a value range is given using the form int[Min:Max] or int[Min:Max step Step] where the Min and Max values are inclusive. If either Min or Max are missing, this indicates no limit. If Step is missing, this indicates a step of 1. Multiple comma-separated ranges can be specified, in which case the value will be in one of the ranges.

long -

Long integer in the range -9223372036854775808 to 9223372036854775807, inclusive.

For some long types, a value range is given using the form long[Min:Max] or long[Min:Max step Step], where the Min and Max values are inclusive. If either Min or Max are missing, this indicates no limit. If Step is missing, this indicates a step of 1. Multiple comma-separated ranges can be specified, in which case the value will be in one of the ranges.

object - A container for parameters and/or other objects. The full Path Name of a parameter is given by the parameter name appended to the full Path Name of the object it is contained within.
string - For strings, a minimum and maximum allowed length can be indicated using the form string(Min:Max), where Min and Max are the minimum and maximum string length in characters. If either Min or Max are missing, this indicates no limit, and if Min is missing the colon can also be omitted, as in string(Max). Multiple comma-separated ranges can be specified, in which case the string length will be in one of the ranges.
unsignedInt -

Unsigned integer in the range 0 to 4294967295, inclusive.

For some unsignedInt types, a value range is given using the form unsignedInt[Min:Max] or unsigned[Min:Max step Step], where the Min and Max values are inclusive. If either Min or Max are missing, this indicates no limit. If Step is missing, this indicates a step of 1. Multiple comma-separated ranges can be specified, in which case the value will be in one of the ranges.

unsignedLong -

Unsigned long integer in the range 0 to 18446744073709551615, inclusive.

For some unsignedLong types, a value range is given using the form unsignedLong[Min:Max] or unsignedLong[Min:Max step Step], where the Min and Max values are inclusive. If either Min or Max are missing, this indicates no limit. If Step is missing, this indicates a step of 1. Multiple comma-separated ranges can be specified, in which case the value will be in one of the ranges.

References

[802.1D-2004] IEEE Std 802.1D-2004, Media Access Control (MAC) Bridges, IEEE, 2004.
[802.1Q-2005] IEEE Std 802.1Q-2005, Virtual Bridged Local Area Networks, IEEE, 2006.
[BLUE] Blue, A New Class of Active Queue Management Algorithms.
[DLNA-NDIG] DLNA Networked Device Interoperability Guidelines, DLNA Networked Device Interoperability Guidelines, Volume 2: Media Format Profiles., DLNA, October 2006.
[DVB-TS.102.824] TS 102 824, Digital Video Broadcasting (DVB);Remote Management and Firmware Update System for DVB IP Services, ETSI, July 2008.
[HTML4.01] HTML 4.01 Specification, W3C.
[ICSA-Firewall] ICSA Modular Firewall Certification Criteria, Required Services Security Policy - Small/Medium Business (SMB) Category module - version 4.0, ICSA Labs.
[ISO-13818-6:1998] ISO/IEC 13818-6:1998, Information Technology - Generic coding of moving pictures and associated audio information - Part 6: Extensions for DSM-CC, ISO, 1998.
[OUI] Organizationally Unique Identifiers (OUIs).
[RED] References on RED (Random Early Detection) Queue Management.
[RFC793] RFC 793, Transmission Control Protocol, IETF, September 1981.
[RFC862] RFC 862, Echo Protocol, IETF, 1983.
[RFC959] RFC 959, File Transfer Protocol, IETF, 1985.
[RFC1323] RFC 1323, TCP Extensions for High Performance, IETF, May 1992.
[RFC2131] RFC 2131, Dynamic Host Configuration Protocol, IETF.
[RFC2132] RFC 2132, DHCP Options and BOOTP Vendor Extensions, IETF.
[RFC2225] RFC 2225, Classical IP and ARP over ATM, IETF.
[RFC2474] RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, IETF.
[RFC2516] RFC 2516, A Method for Transmitting PPP Over Ethernet (PPPoE), IETF.
[RFC2581] RFC 2581, TCP Congestion Control, IETF, April 1999.
[RFC2582] RFC 2582, The NewReno Modification to TCP's Fast Recovery Algorithm, IETF, April 1999.
[RFC2616] RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, IETF, 1999.
[RFC2634] RFC 2634, Enhanced Security Services for S/MIME, IETF.
[RFC2662] RFC 2662, Definitions of Managed Objects for the ADSL Lines, IETF.
[RFC2684] RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5, IETF.
[RFC2697] RFC 2697, A Single Rate Three Color Marker, IETF.
[RFC2698] RFC 2698, A Two Rate Three Color Marker, IETF.
[RFC2818] RFC 2818, HTTP Over TLS, IETF, May 2000.
[RFC2898] RFC 2898, PKCS #5: Password-Based Cryptography Specification Version 2.0, IETF.
[RFC2974] RFC 2974, Session Announcement Protocol, IETF, October 2000.
[RFC3004] RFC 3004, The User Class Option for DHCP, IETF.
[RFC3066] RFC 3066, Tags for the Identification of Languages, IETF.
[RFC3489] RFC 3489, STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), IETF.
[RFC3925] RFC 3925, Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4), IETF.
[RFC3926] RFC 3926, FLUTE - File Delivery over Unidirectional Transport, IETF, October 2004.
[RFC3986] RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, IETF.
[RFC4122] RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace, IETF, 2005.
[RFC4291] RFC 4291, IP Version 6 Addressing Architecture, IETF, 2006.
[RFC4632] RFC 4632, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan, IETF, 2006.
[SOAP1.1] Simple Object Access Protocol (SOAP) 1.1, W3C.
[TR-069] TR-069, CPE WAN Management Protocol, Broadband Forum, 2004.
[TR-069a1] TR-069 Amendment 1, CPE WAN Management Protocol, Broadband Forum, 2006.
[TR-069a2] TR-069 Amendment 2, CPE WAN Management Protocol, Broadband Forum, 2007.
[TR-069a4] TR-069 Amendment 4, CPE WAN Management Protocol, Broadband Forum, 2011.
[TR-098] TR-098, Internet Gateway Device Data Model for TR-069, Broadband Forum, 2005.
[TR-098a1] TR-098 Amendment 1, Internet Gateway Device Data Model for TR-069, Broadband Forum, 2006.
[TR-098a2] TR-098 Amendment 2, Internet Gateway Device Data Model for TR-069, Broadband Forum, 2008.
[TR-106] TR-106, Data Model Template for TR-069-Enabled Devices, Broadband Forum, 2005.
[TR-106a1] TR-106 Amendment 1, Data Model Template for TR-069-Enabled Devices, Broadband Forum, 2006.
[TR-106a2] TR-106 Amendment 2, Data Model Template for TR-069-Enabled Devices, Broadband Forum, 2008.
[TR-106a3] TR-106 Amendment 3, Data Model Template for TR-069-Enabled Devices, Broadband Forum, 2009.
[TR-143] TR-143, Enabling Network Throughput Performance Tests and Statistical Monitoring, Broadband Forum, 2008.
[TR-157] TR-157, Component Object for CWMP, Broadband Forum, March 2009.
[UPnP-DAv1] UPnP Device Architecture, UPnP Device Architecture 1.0, UPnP Forum, April 2008.
[USB1.0] USB 1.0, USB 1.0 Specification, USB-IF, January 1996.
[USB2.0] USB 2.0, USB 2.0 Specification, USB-IF, April 2000.
[USB3.0] USB 3.0, USB 3.0 Specification, USB-IF, November 2008.
[WPSv1.0] Wi-Fi Protected Setup Specification Version 1.0h, Wi-Fi Alliance, 2006.
[ZigBee2007] ZigBee 2007 Specification, ZigBee 2007 Specification, ZigBee Alliance, October 2007.

TR-157:1.1 Data Model

For a given implementation of this data model, the Agent MUST indicate support for the highest version number of any object or parameter that it supports. For example, even if the Agent supports only a single parameter that was introduced in version 1.1, then it will indicate support for version 1.1. The version number associated with each object and parameter is shown in the Version column.

Name Type Write Description Object Default Version
DeviceInfo. object -   - 1.1
SupportedDataModelNumberOfEntries unsignedInt - Number of entries in the SupportedDataModel table. - 1.1
DeviceInfo.SupportedDataModel.{i}. object -

This table contains details of the device's Current Supported Data Model.

The table MUST describe the device's entire Supported Data Model. Therefore, if a device's Supported Data Model changes at run-time, entries will need to be added or removed as appropriate.

Each table entry MUST refer to only a single Root Object or Service Object. The device MAY choose to use more than one table entry for a given Root Object or Service Object.

Considering that every device has some form of a data model, this table MUST NOT be empty.

At most one entry in this table can exist with a given value for URL.

- 1.1
URL string­(256) -

URL ([RFC3986]) that describes some or all of the device's Current Supported Data Model.

The URL MUST reference an XML file which describes the appropriate part of the Supported Data Model.

The referenced XML file MUST be compliant with the DT (Device Type) Schema that is described in [Annex B/TR-106a3], including any additional normative requirements referenced within the Schema.

The XML file referenced by this URL MUST NOT change while the CPE is running, and SHOULD NOT change across a CPE reboot. Note that, if the same XML file is to be used for multiple CPE, this strongly suggests that the XML file referenced by this URL should never change.

The URL MAY permit the XML file to be accessed at run-time, in which case, the XML file MAY be located within the CPE.

Behavior in the event of an invalid URL, failure to access the referenced XML file, or an invalid XML file, is implementation-dependent.

- 1.1
URN string­(256) -

URN ([RFC3986]) that is the value of the spec attribute in the DM (data model) Instance that defines the Root Object or Service Object referenced by this table entry.

For example, if this table entry references a DT Instance that refers to the Device:1.3 Root Object, the value of this parameter would be urn:broadband-forum-org:tr-157-1-0-0, because TR-157 defines Device:1.3. If the DT Instance instead referred to a vendor-specific Root Object, e.g. X_EXAMPLE_Device:1.0 (derived from Device:1.3), the value of this parameter would be something like urn:example-com:device-1-0-0.

- 1.1
Features string -

Comma-separated list of strings. This parameter MUST list exactly the features that are defined using the top-level feature element in the DT Instance referenced by URL.

For example, if the DT instance specified the following:

<feature name="DNSServer"/>
<feature name="Router"/>
<feature name="X_MyDeviceFeature"/>

then the value of this parameter might be DNSServer,Router,X_MyDeviceFeature. The order in which the features are listed is not significant.

- 1.1

Inform and Notification Requirements

Forced Inform Parameters

Parameter

Forced Active Notification Parameters

Parameter

Default Active Notification Parameters

Parameter

Parameters for which Active Notification MAY be Denied

Parameter

Profile Definitions

Notation

The following abbreviations are used to specify profile requirements:

Abbreviation Description
R Read support is REQUIRED.
W Both Read and Write support is REQUIRED. This MUST NOT be specified for a parameter that is defined as read-only.
P The object is REQUIRED to be present.
C Creation and deletion of instances of the object is REQUIRED.
A Creation of instances of the object is REQUIRED, but deletion is not REQUIRED.
D Deletion of instances of the object is REQUIRED, but creation is not REQUIRED.

SupportedDataModel:1 Profile

This table defines the SupportedDataModel:1 profile for the TR-157:1 data model. The minimum REQUIRED version for this profile is TR-157:1.1.

Name Requirement
DeviceInfo. P
SupportedDataModelNumberOfEntries R
DeviceInfo.­SupportedDataModel.­{i}. P
URL R
URN R
Features R


Generated by Broadband Forum report.pl#422 (2018/03/28 version) on 2018/04/02 at 12:27:06.
report.pl --exitcode=fatals --cwmpindex=.. --nofontstyles --nowarnreport --quiet --nomodels --automodel --report=html --outfile=tr-157-1-1-0.html tr-157-1-1-0.xml