Stand straight Keep an open posture Step forward when starting
The ACS sends ScheduleInform to instruct CPE to connect back after a period of time Example applications When periodic inform interval is less than 24 hours, ScheduleInform allows an ACS to schedule the CPE to report back at the right time (e.g. during a nightly maintenance window) for e.g. firmware upgrades. This possibly eliminates the need for the ACS to initiate connection requests to large numbers of devices. The ScheduleInform RPC will be supported. When receiving a ScheduleInform RPC with DelaySeconds different from 0, a TimeOfDay schedule will be used to event upon expiration of the number of seconds (TimeOfDay will convert this to an absolute time to support device power-off during the time period). TimeOfDay schedule is using minute granuarlity so the DelaySeconds will be “rounded” to minutes (60seconds). After expiration of the time (rounded to minutes), a connection to the ACS will be established to send an Inform RPC with “3 SCHEDULED” and “M Scheduleinform” events. Application : schedule device to report back at night to perform e.g. firmware upgrades during a maintenance time window The Inform RPC sent to the ACS after the time expiration will include a “M ScheduleInform” Inform event.
Customizable Forced Inform Parameter List The Inform parameters list will be customizable with configurable parameters (full IGD model path) to the required that are sent in addition parameters listed in CWMP_R30. KTI2209: Send PPP Username as Inform Parameter for Belgacom
TR-69 Amendment 1  specifies a session termination that differs from the original TR-69 specification. It differs in two aspects: 1. NoMoreRequests header element is deprecated 2. Session considered terminated if the CPE has sent an empty POST before (Amendment 1) vs. in the previous message (original TR-69). NoMoreRequests will not be used. Session termination will be configurable via CLI to either be according to the original TR-69 specification or be according to TR-69 Amendment 1. Factory default customization allows choosing the mechanism used per customer.
Postponing the service interrupting step of firmware upgrade upon detection of (customizable) service activity as specified in  will be supported (for RTEMS and GoLinux products).
TR-64 “LAN-Side DSL CPE Configuration Specification” was started because of the need for a standard interface for PC-based (LAN-side) install applications. Based upon the UPnP Device Architecture, extensions where defined to meet the LAN-side CPE configuration requirements.
Differences between TR-64 and UPnP:
Separate root device and namespace (co-exists independent from UPnP)
No support for eventing (GENA)
Digest Authentication per SOAP action
Optional use of SSL/TLS ( Secure Socket Layer/Transport Layer Security)
Transactional semaphores to prevent simultaneous configuration by multiple control points
Different modeling of some connection models (PPPoE) by LinkType/ConnectionType
When a file transfer is complete (e.g. after firmware upgrade)
When a diagnostics test is complete
On each connection establishment, the CPE sends the Inform RPC to the server which contains the reason/event for the connection establishment.
The CPE will keep on sending HTTP requests to the server to allow the server to respond with RPCs until both have nothing more to send.
TR-69: Example message flow Example management session message flow The CPE is responsible for establishing the session to the server The CPE keeps sending HTTP POST requests during the session. The session is closed as soon as both CPE and ACS have indicated they have nothing more to send (response or new RPC)
CWMP Related Specifications WT-131, WT132 ACS Northbound Interface TR-69 CWMP Am.1 TR-98 Am.1 IGD Model TR-111 CWMP for Home Devices TR-64 LAN CPE Auto-Configuration WT-135 STB Model TR-104 VoIP Model WT-140 Network Storage Model TR-106 CWMP Enabled Device Model Template TR-104 VoIP Model
getvalues: retrieve the values of one or more parameters of a specific object.
setvalues: write a value to one or more parameters of an object Rollback for this action is supported at client command level.
getcount: this action returns the number of parameter/value pairs that would be returned if a getvalues is called with the same arguments. This allows you to determine how much memory needs to be allocated to store all parameters or determine the number of objects of a specific type.
addobject: add an object to the data model.
deleteobject: delete an object from the data model.
subscribe: subscribe a client to the MBus event.
unsubscribe: unsubscribe a client from the MBus event.