hugoweaver11

Most of a configuration and diagnostics is carried out through setting and retrieving the value of the machine parameters. These are sorted out in well defined hierarchical structure that is pretty much common to all of device models in addition to manufacturers. Broadband Forum will be publishing its facts model standards with two formats -- XML files including detailed specification of each subsequent data-model and the many changes between their versions and PDF FILE files containing human-readable particulars. Supported standards and extensions should be clearly marked inside device data-model. This could be in your field Device. DeviceSummary or InternetGatewayDevice. DeviceSummary which is required starting because of Device: 1. 0 together with InternetGatewayDevice: 1. 1 respectively. If ever the field is never found InternetGatewayDevice: 1. 0 is actually implied. As regarding Device: 1. 4 and InternetGatewayDevice: 1. 6 new field meant for supported standard standard was introduced.

Model is always rooted within the single key named Device or InternetGatewayDevice according to manufacturers choice. At each amount of the structure materials and parameters (and array-instances) are generally allowed. Keys can be constructed by concatenating a names of items and parameter together with using '. '(dot) as a separator. Ex. InternetGatewayDevice. Time. NTPServer1.

Each of the parameters may end up marked as writable or even non-writable. This is reported from the device in GetParameterNamesResponse sales message. Device should not let the change of any parameter marked when read-only. Data-model specifications and extensions clearly marked required status of the very of the parameters.

Values applicable to your parameter, their type and meaning are also precisely defined through the standard.

tr069