Component Object definitions
TR-157 Issue 1 Amendment 8
Parameters related to CPE behavior when waking up from standby. If this object is supported then the CPE MUST support the requirements of {{bibref|TR-069a5|Annex L}}.
NOTE: "CR", as used in the names and descriptions of the parameters defined in this object, refers to the Connection Request concept defined in TR-069.
When waking up from a non CR-Aware Standby that lasted more than this parameter's value (in {{units}}), the CPE MUST issue a WAKEUP Event.
If the value is -1, the CPE MUST NOT ever issue WAKEUP Events for having been non CR-aware.
When waking up from a non fully Timer-Aware Standby that made it miss more than this parameter's value Periodic Contacts, the CPE MUST issue a WAKEUP Event.
If the value is -1, the CPE MUST NOT ever issue WAKEUP Events for exceeding that limit.
When waking up from a non fully Timer-Aware Standby that made it miss at least one Scheduled Contact, the CPE MUST issue a WAKEUP Event if this parameter is {{true}}.
Indicates that the CPE is capable of CR-Aware Standby.
Indicates that the CPE is capable of Timer-Aware Standby.
If {{param|NetworkAwarenessCapable}} and this parameter are both {{true}}, the CPE MUST NOT go into a non CR-Aware Standby state.
If {{param|SelfTimerCapable}} and this parameter are both {{true}}, the CPE MUST NOT go into a standby state that prevents it from honoring Periodic Contacts.
If this parameter is true, the CPE MUST NOT go into a standby state that prevents it from honoring Scheduled Contacts. This means that, whenever the ACS has requested a Scheduled Contact:
*if {{param|SelfTimerCapable}} is {{true}} and the CPE chooses to go into Standby before the Scheduled Contact has been honored, it MUST use a Timer-Aware Standby;
*if {{param|SelfTimerCapable}} is {{false}}, the CPE MUST NOT go into Standby before the Scheduled Contact has been honored.
Note that support for this profile implies support for the requirements of {{bibref|TR-069a5|Annex L}}.
The {{object}} represents the XMPP capabilities of the device as described in {{bibref|TR-069a5|Appendix III}}.
{{numentries}}
The {{object}} represents a XMPP connection between the device and a server. The {{param|Username}}, {{param|Domain}} and {{param|Resource}} comprise the full identity (JabberID) of this {{object}} for this device.
Enables or disables this {{object}}.
This parameter is based on ''ifAdminStatus'' from {{bibref|RFC2863}}.
{{datatype|expand}}
The proposed local-part of the Jabber ID of this {{object}}, and the value to be used to authenticate this {{object}} when making a connection to the Server using the procedure outlined in {{bibref|RFC6120|Section 6}}.
Password used to authenticate this {{object}} when making a connection to the {{object|Server}} using the procedure outlined in {{bibref|RFC6120|Section 6}}.
Note that on a factory reset of the CPE, the value of this parameter might be reset to its factory value. If an ACS modifies the value of this parameter, it SHOULD be prepared to accommodate the situation that the original value is restored as the result of a factory reset.
The proposed domain-part of the Jabber ID of this {{object}}.
The proposed resource-part of the Jabber ID of this {{object}}.
The complete Jabber ID as determined by the first-hop XMPP server at time of connection establishment. This Jabber ID will usually be the standard concatentation of the local-part (Username), domain-part (Domain), and resource-part (Resource) as defined in {{bibref|RFC6120|Section 2.1}} (local-part@domain-part/resource-part), but since the Jabber ID is owned by the first-hop XMPP Server there are cases where the value will be different.
The current operational state of this {{object}} (see {{bibref|TR-181i2|Section 4.2.2}}). {{enum}}
When {{param|Enable}} is {{false}} then {{param}} SHOULD normally be {{enum|Disabled}} or {{enum|Error}} if there is a fault condition on the interface).
When {{param|Enable}} is changed to {{true}} then {{param}} SHOULD change to {{enum|Enabled}} if and only if the interface is able to transmit and receive PDUs; it SHOULD change to {{enum|Dormant}} if and only if the interface is operable but is waiting for external actions before it can transmit and receive network traffic (and subsequently change to {{enum|Enabled}} if still operable when the expected actions have completed); it SHOULD change to {{enum|Unknown}} if the state of the interface can not be determined for some reason.
The date and time at which this {{object}} entered into its current operational state.
The algorithm the {{object}} uses when connecting with the associated lists of servers. {{enum}}
Use the connection algorithm as specified in {{bibref|RFC6120|Section 3.2}} where the value of the {{param|Domain}} parameter is used to look up the server address and port to use. Use the instances of the {{object|Server}} table based on the values of the {{param|Server.{i}.Priority}} and {{param|Server.{i}.Weight}} parameters as the basis for reconnect. Instances must be reachable and reachable instances with the lowest value MUST be preferred.
The number of {{units}} that keep alive events as specified in {{bibref|RFC6120|Section 4.6.1}} are sent by this {{object}}.
A value of 0 disables the keep alive functionality. A value of -1 indicates that the keep alive interval is a vendor specific implementation.
{{bibref|RFC6120|Section 4.6.4}} recommends not checking more frequently than every 5 minutes (or 300 {{units}}).
The number of times that this {{object}} attempts to connect to a given IP address before moving on to the current server's next IP address, or to the next server if the current server has no more IP addresses.
If {{param}}, {{param|ServerRetryInitialInterval}}, {{param|ServerRetryIntervalMultiplier}} and {{param|ServerRetryMaxInterval}} all have their default values, the maximum reconnection wait intervals, in ''minutes'', will be ''{1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 512, 512, 512, 512, 512}''. After the initial attempt there are 15 further attempts, making a total of 16. The maximum reconnection wait interval is reached on the 10th retry, i.e. the 11th attempt.
NOTE: If this {{object}} fails to connect to any of the servers' IP addresses, fallback behavior SHOULD be as specified in {{bibref|RFC6120|Section 3.2}}.
NOTE: If the value of this parameter is 0, server connection and reconnection behavior is implementation-dependent.
The maximum first reconnection wait interval, in {{units}}, as specified in {{bibref|TR-069a5|Annex K XMPP Connection Request}}.
The Device MUST use a random value between ''0'' and {{param}} as the first reconnection wait interval.
NOTE: If the value of the {{param|ServerConnectAttempts}} parameter is 0, the value of this parameter is ignored.
The reconnection interval multiplier as specified in {{bibref|TR-069a5|Annex K XMPP Connection Request}}. This value is expressed in units of 0.001. Hence the values of the multiplier range between 1.000 and 65.535.
For the ''n''th reconnection wait interval, the Device MUST use a random value, in ''seconds'', between ''0'' and {{param|ServerRetryInitialInterval}} * ({{param}} / 1000) ** (''n'' - ''1'').
NOTE: If the value of the {{param|ServerConnectAttempts}} parameter is 0, the value of this parameter is ignored.
The maximum reconnection wait interval, in {{units}}.
If the ''n''th reconnection wait interval calculated from {{param|ServerRetryInitialInterval}} and {{param|ServerRetryIntervalMultiplier}} exceeds the value of this parameter, then the Device MUST use the value of this parameter as the next reconnection wait interval.
NOTE: If the value of the {{param|ServerConnectAttempts}} parameter is 0, the value of this parameter is ignored.
This parameter allows an ACS to configure whether or not this XMPP Connection is required to use TLS independent of whether or not the XMPP Server that is being connected to is configured for TLS "mandatory-to-negotiate".
If the value of {{param}} is {{true}} then the CPE will initiate TLS negotiation if not required to by the XMPP Server.
If the value of {{param}} is {{false}} then the CPE will not initiate TLS negotiation if not required to by the XMPP Server.
This parameter represents the TLS state of this XMPP Connection.
If this XMPP Connection is established and is secured by TLS then the value of this parameter is {{true}}.
If this XMPP Connection is either not established or established but not secured by TLS then the value of this parameter is {{false}}.
{{numentries}}
The {{object}} represents an XMPP server to be used for a {{object|##.Connection}}.
This table is only relevant when {{param|##.Connection.{i}.ServerConnectAlgorithm}} is set to {{enum|ServerTable|##.Connection.{i}.ServerConnectAlgorithm}}. If {{param|##.Connection.{i}.ServerConnectAlgorithm}} is set to {{enum|DNS-SRV|##.Connection.{i}.ServerConnectAlgorithm}} then any instances of this table are ignored by this {{object|##.Connection}}.
Enables or disables this {{object}}.
This parameter is based on ''ifAdminStatus'' from {{bibref|RFC2863}}.
{{datatype|expand}}
The priority of this {{object}} that is used by the {{object|##.Connection}} when determining the {{object}} to connect. The {{object|##.Connection}} MUST contact the {{object}} with the lowest-numbered priority that the {{object|##.Connection}} can reach as defined in {{bibref|RFC2782}}. The selection of {{object}}s with the same {{param}} value utilizes the {{param|Weight}} parameter to determine which {{object}} is selected by the {{object|##.Connection}}.
This parameter specifies a relative weight for entries with the same {{param|Priority}}. The mechanism is defined in {{bibref|RFC2782}}. A value of -1 indicates that the implementation of this parameter is specific to the Vendor.
Fully Qualified Domain Name (FQDN) or IP address of the XMPP server for this {{object|##.Connection}}.
If the value of this Parameter is a FQDN that resolves to multiple addresses then each address SHOULD be attemtped (in an implemnetation-specific order) until a connection can be made or all addresses are exhausted, in which case the next {{object}} instance (based on {{param|Priority}} and {{param|Weight}}) SHOULD be used.
Port number of the XMPP server for this {{object|##.Connection}}.
XMPP Connection statistics information for this resource.
The number of XMPP stanzas (iq, presence, or message) that have been received on this {{object|##.Connection}}.
The number of XMPP stanzas (iq, presence, or message) that have been transmitted by this {{object|##.Connection}}.
The number of XMPP stanzas (iq, presence, or message) that have been received on this {{object|##.Connection}} where the type attribute had a value of "error".
The number of XMPP stanzas (iq, presence, or message) that have been transmitted by this {{object|##.Connection}} where the type attribute had a value of "error".
The connection request methods supported by this {{object}}. {{enum}}
The connection request method as specified in {{bibref|TR-069|Section 3.2.2 ACS Connection Initiation}}, '''REQUIRED'''
The connection request method as specified in {{bibref|TR-069|Annex G Connection Request via NAT Gateway}}
The connection request method as specified in {{bibref|TR-069a5|Annex K XMPP Connection Request}}
{{reference|the {{object|.XMPP.Connection}} instance that is used for connection requests to this {{object}}}}
When an XMPP Connection Request is sent to a CPE the XMPP IQ Stanza will contian a "from" address that contains the Jabber ID of the initiating entity.
This parameter is a {{list}} Each entry represents a Jabber ID, or address, that is allowed to initiate an XMPP Connection Request.
Each Jabber ID is allowed to be either a "Full JID" (containing a local-part, domain-part, and resource-part in the following format: "local-part@domain-part/resource-part") or a "Bare JID" (containing a local-part and a domain-part in the following format: "local-part@domain-part"). "Full JID" entries require an exact match whereas "Bare JID" entries are a wildcard match and will match any Jabber ID with the same local-part and domain-part independent of the resource-part.
For example, if {{param}} contained "ACS1@tr069.example.com, ACS2@tr-069.example.com/resource1" then the following incoming "from" addresses would be '''allowed''':
* "ACS1@tr069.example.com/resource1"
* "ACS1@tr069.example.com/resource2"
* "ACS2@tr069.example.com/resource1"
And the following incoming "from" addresses '''would not be allowed''':
* "ACS2@tr069.example.com/resource2"
* "ACS@tr069.example.com/resource"
If this Parameter is {{empty}} then all Jabber IDs are allowed and an XMPP Connection Request can not be deemed invalid due to the "from" address.
The value MUST be the value of the {{param|.XMPP.Connection.{i}.JabberID}} contained in the {{object|.XMPP.Connection}} instance referenced by the {{param|ConnReqXMPPConnection}} parameter.
If the {{param|ConnReqXMPPConnection}} parameter is empty or the {{object|.XMPP.Connection}} instance being reference is disabled, then this value will be empty.
If the {{object|.XMPP.Connection}} instance being referenced by the {{param|ConnReqXMPPConnection}} parameter is lost ({{param|.XMPP.Connection.{i}.Status}} parameter changes from Enabled to some other value), then the value of this parameter MUST remain unchanged until the connection can be reestablished and a new {{param|.XMPP.Connection.{i}.JabberID}} can be established. If the new {{param|.XMPP.Connection.{i}.JabberID}} is identical to the existing value, then the value of this parameter MUST NOT be altered and a VALUE CHANGE event MUST NOT be generated.
Indicates the HTTP Compression mechanism(s) supported by this CPE. Requirements for the use of HTTP Compression for CWMP can be found in {{bibref|TR-069a5|Section 3.4.7}}. {{enum}}
Vendors can extend the enumerated values with vendor specific extensions, in which case the rules outlined in {{bibref|TR-106a7|Section 3.3}} MUST be adhered to.
As defined in {{bibref|RFC2616|Section 3.5}}
As defined in {{bibref|RFC2616|Section 3.5}}
As defined in {{bibref|RFC2616|Section 3.5}}
The value of this parameter represents the HTTP Compression mechanism to be used by the CPE when communicating with the ACS.
Indicates the Lightweight Notification Protocol(s) supported by this CPE. {{enum}}
Vendors can extend the enumerated values with vendor specific extensions, in which case the rules outlined in {{bibref|TR-106a7|Section 3.3}} MUST be adhered to.
As defined in {{bibref|TR-069a5|Annex M}}
The value of this parameter represents the protocol(s) that will be used by the CPE when sending Lightweight Notifications.
{{empty}} means that Lightweight Notifications are disabled, despite any SetParameterAttributes that have been configured on various parameters.
Host name or address to be used when sending the UDP Lightweight Notifications.
{{param}} is only applicable when {{param|LightweightNotificationProtocolsUsed}} contains the {{enum|UDP|LightweightNotificationProtocolsUsed}} enumeration.
If {{param}} is not implemented or is {{empty}}, and UDP Lightweight Notifications are supported, the destination host MUST be the same as the ACS (as contained in the host portion of the {{param|URL}}).
The port number to be used when sending UDP Lightweight Notifications.
{{param}} is only applicable when {{param|LightweightNotificationProtocolsUsed}} contains the {{enum|UDP|LightweightNotificationProtocolsUsed}} enumeration.
If {{param}} is not implemented and UDP Lightweight Notifications are supported, the destination port MUST be 7547.