The Role of Notify Request and Retry Algorithm in TR-369 USP
In the TR-369 USP (User Services Platform), the Notify request plays a critical role. It includes a flag called send_resp, which specifies whether a Controller should send a response message after receiving a Notify request. The Notify request and the retry process when the notification isn't acknowledged are critical components in TR-369, which we'll dissect in this blog.
The send_resp Flag and NotifRetry Parameter
In a TR-369 USP environment, the Notify request functions with a flag called send_resp. This flag determines whether the Controller should return a response message upon receipt of a Notify request.
When send_resp is set to true, the Agent sends its Notify requests. The notification is considered delivered when the Agent receives a response from the Controller. However, when send_resp is set to false, the Agent does not require a response and delivery state of the notification.
Retry Process and NotifExpiration Parameter
In a scenario where send_resp is true but the send_resp doesn't send_resp a response from the Controller, the Agent initiates a retry process following a specific retry algorithm. The subscription object uses a NotifExpiration parameter to specify the expiration time for this retry process if no successful delivery occurs.
The Retry Algorithm
The retry algorithm for managing the retransmission of the Notify request is defined in the following way. It controls the retry interval range using two parameters: the minimum wait interval and the interval multiplier.
| Attempt | Default Wait Interval Range | Actual Wait Interval Range |
|---|---|---|
| #1 | 5-10 | m - m.(k/1000) |
| #2 | 10-20 | m.(k/1000) - m.(k/1000)^2 |
| #3 | 20-40 | m.(k/1000) - m.(k/1000)^3 |
| #4 | 40-80 | m.(k/1000) - m.(k/1000)^4 |
| #5 | 80-160 | m.(k/1000) - m.(k/1000)^5 |
| #6 | 160-320 | m.(k/1000) - m.(k/1000)^6 |
| #7 | 320-640 | m.(k/1000) - m.(k/1000)^7 |
| #8 | 640-1280 | m.(k/1000) - m.(k/1000)^8 |
| #9 | 1280-2560 | m.(k/1000) - m.(k/1000)^9 |
| #10 and subsequent | 2560-5120 | m.(k/1000) - m.(k/1000)^10 |
For example, consider the values for these parameters: the minimum wait interval (m) is 5 seconds, and the interval multiplier (k) is 2000. The retry intervals for the first 10 attempts and subsequent attempts are defined by mathematical formulas involving these two parameters.
If the retrying of a notification fails, the Agent continues to retry until the notification is successfully delivered or until the NotifExpiration time is reached. After successful delivery, the Agent resets the retry count to zero for the next notification message. Similarly, if the Agent reboots, it resets the retry count to zero for the next notification message.
By understanding the Notify request mechanism, the role of the send_resp flag, the Notify Retry and Notify Expiration concepts, and the retry algorithm, we can better comprehend the TR-369 USP protocol. This understanding leads to more efficient and effective management of IoT devices.