Article Original Creation Date: 2015-05-21
Overview
This article aims to provide you information on the types of Value Change event and how to get the changed value in the policy.
These 2 values are:
- The one that sends the changed value immediately.
- The one that sends the changed value in the next periodic inform.
Reference Information
These values are called notifications and they are described in section A.3.2.4 in the TR-069 specification, as mentioned below. Notifications define whether a parameter should be included in an Inform message when its value changes.
There are 3 types of notifications:
- Notification off
- This means that the CPE does not need to notify the ACS of a change to the specified parameter.
- Passive notification
- When a specified parameter value changes, the CPE MUST include that parameter (and its new value) in the ParameterList struct of the next Inform message that the device sends to the ACS. The next Inform message could be something like a BOOT or a PERIODIC, and it MUST include that parameter (and its new value) in the ParameterList struct, and it also MUST include the “4 VALUE CHANGE” event code in the list of Events in the Inform message.
- Active notification
- Whenever the specified value changes, the CPE MUST initiate a session with the ACS (send a VALUE CHANGE Inform) and include the parameter (and its new value) in the ParameterList struct in the Inform.
There are 3 things you can do on the Out-of-the-Box (OOTB) with the values in a VALUE CHANGE inform:
- CWMP Parameter Mapping
- You can map a parameter from the ParameterList in an Inform to either a system key or an attribute on the device. Each time an Inform comes in with that parameter, the parameter mapping will update the value in either the system key or the attribute on the device. Note that this does not keep historical values, only the most recent value included in the Inform. Note that parameter mapping works for all Inform types, not just VALUE CHANGE informs, so it could also update values for other types of Informs as well.
- Update CWMP Cache on Value Change policy action
- This policy action will take any parameters included in the ParameterList of a VALUE CHANGE Inform that are flagged to be cached (more on this in a moment) and it will store them in the DB. You can view these cached values in the Object Cache tab when viewing a device in the UI. As for flagging a parameter to be cached, you do this in the data model. So you need to go to the Configuration Data Models screen and select a parameter you are interested in from a given data model. When viewing that parameter, you will see a checkbox called ‘Cache Values’. If you check that box and save it, then the next time this policy action runs it will store that parameter value in the database, and you can view it on the Object Cache tab. One thing to be aware of here is that I believe you need to set that ‘Cache Values’ flag on a Data Model that belongs to a capability that the device has. For instance, if the device has the Device:2.0 capability, but you check the ‘Cache Values’ checkbox on the Device:2.4 data model, then it might not cache the value. I am not 100% sure about this last part, but I seem to recall that it worked that way. So definitely worth noting, at least. One benefit of using this policy action is that it can be associated only with the Value Change event, so it would not apply to all Inform types.
- Forward Value Change to SNMP Manager
- This policy action also works on the ParameterList in a VALUE CHANGE Inform. With this one, you can select the parameters you are interested in and specify a test for that parameter (is the parameter included in the list, is its value within a certain range, etc), and if the tests pass, it will forward that parameter and value as an SNMP Trap to some other entity.
Priyanka Bhotika
Comments