Every TR-069 session is initiated by a CWMP endpoint that is looking to deliver an event. These events have different delivery requirements, using language such as “must not discard”, “must retry until reboot”, “may retry” and “must not retry”.
What happens when the CPE tries to deliver an event but cannot reach the ACS? TR-069 defines an explicit session retry policy to deal with this scenario.
An unsuccessful session is considered equivalent with an undelivered event. This means that a successful session involves the completion of the Inform RPC; that is, the CPE makes the Inform call and the ACS responds. A session can be considered unsuccessful if the Inform RPC never completes. As far as the CPE is concerned, the ACS has not received the events.
Every Inform RPC the CPE makes contains the RetryCount argument. This number is reset to 0 after every successful session.
When a session is unsuccessful, the CPE follows a session retry procedure. Each time it retries a session, it increments the RetryCount by 1.
In the CPE data model, under the ManagementServer object, there are two parameters that control this behavior - CWMPRetryMinimumWaitInterval (in seconds) and CWMPRetryIntervalMultiplier (in milliseconds). These default to 5 seconds and 2000 milliseconds, respectively.
The CPE waits to retry the session after a random time between the RetryMinimumWaitInterval and the WaitInterval times the RetryIntervalMultiplier. This time is random to prevent large numbers of CPE from all trying to reconnect to the ACS at the same time.
If a new event requiring a session occurs during this period, the connection is retried immediately.
When it does retry, it increments the RetryCount to 1. If it fails again, it increments it to 2, and so on. Each time, it increases the random wait interval range exponentially by a factor of the IntervalMultiplier converted into seconds, and picks a random period to wait in a range generated according to the following formula:
Previous Maximum Wait Interval to (CWMPRetryMinimumWaitInterval*(IntervalMultiplier)^RetryCount)
The previous maximum range becomes the new minimum. The new maximum range becomes the CWMPRetryMinimumWaitInterval times the IntervalMultiplier (in seconds) to the power of RetryCount.
For example, with the defaults, the first range would be 5-10 seconds. On the second retry, it would be 10-20 seconds, and so on. This reaches a maximum range after the 10th retry.
Develop your solution even faster with the industry standard in automated, expert testing.
