How Telemetry Profiles Get to Devices

The Telemetry 2 Telemetry Framework (T2) can process legacy Telemetry 1/1.1 style report profiles (sometimes called the DCM configuration or DCA telemetry), and it can also process the new T2-style report profiles described here.   But how are these profiles received by the CPE so that they can be processed?  The two styles of profiles (T1/T1.1 and T2) are received via different mechanisms.

Let's take a step back and look at how the telemetry profile was downloaded by the DCA script, prior to Telemetry 2.

Telemetry 1 & 1.1 profile processing

With the DCA script, the URL to XConf is built into the firmware.

When Telemetry 2 is enabled, the Telemetry 1/1.1 profile is received in the DCM configuration, just as it was prior to Telemetry 2.  The device reaches out to XConf, at boot time and during the maintenance window, to fetch the telemetry 1/1.1 profile.  However, the URL to XConf is configurable for T2 by setting Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.Telemetry.ConfigURL. T2 will use this URL to fetch the legacy telemetry profile. When Telemetry 2 is enabled, this URL can use the XConf API "/loguploader/getT2Settings" to indicate support for the <event> enhancement in T1/T1.1 profiles.

Unlike T2-style profiles, there can only ever be one T1/T1.1 profile active on a device at a time. 

Telemetry 2.0 Report Profiles

Full set of T2 profiles

Unlike the pull mechanism used for the T1/T1.1/legacy telemetry profile, Telemetry 2.0 report profiles are set via the TR-181 data model.  In general, the data model parameters expect a complete set of T2 profiles in the format described here.  There are two different data model properties that can be used to set this full set of profiles: 

• Device.X_RDKCENTRAL-COM_T2.ReportProfiles:  This data model was the original property supported.  It expects the JSON array of profiles in plain string format.
• Device.X_RDKCENTRAL-COM_T2.ReportProfilesMsgPack:  This data model was added to support a msgPack'd JSON array of profiles.  WebConfig is the expected user of this data model.

The T2 component will accept the full set of profiles from either of these data model properties;  however, the last one received will be replace any other T2 profiles on the device.   

Using the data model for T2 report profiles allows the T2 component to be isolated from the delivery mechanism that sets the TR-181.  For instance, WebConfig can be configured and used, but it does not preclude operators from using their own mechanisms to set the T2 profiles. All that is required is that something set one of the TR-181s to the full set of profiles for a device.  Using WebConfig allows easy application of the rules from XConf without requiring any special processing or logic in the T2 component or the device.  See here for more info on WebConfig and XConf for T2 profiles.

Short lived or Temporary T2 profiles

There are use cases for T2 profiles that are short-lived for specific purposes, for instance, for temporarily gathering telemetry at a very fast interval while triaging a customer issue.  For these cases there is a different TR-181 data model property: 

• Device.X_RDKCENTRAL-COM_T2.Temp_ReportProfiles:  This data model expects one or more profiles in a JSON array of profiles. 

These profiles are applied as normal, but will not be persisted across reboots.  In addition, receipt of a full set of profiles via the ReportProfiles or ReportProfilesMsgPack data model properties will completely remove any profiles set via Temp_ReportProfiles.

This allows one-off profiles to be set for a variety of use cases, for instance where a report with a short reporting interval is desired temporarily.

The short-lived profiles will be additive to the full set of persisted profiles expected to be delivered via WebConfig with SET Device.X_RDKCENTRAL-COM_T2.ReportProfilesMsgPack or via SET Device.X_RDKCENTRAL-COM_T2.ReportProfiles, except where any short-lived profile name matches one received in the persisted set. See AC 2.1.2 for details. Regardless, any profile received as a short-lived profile will not be persisted across reboot, restart of T2 process nor any new receipt of profiles via Device.X_RDKCENTRAL-COM_T2.ReportProfiles or Device.X_RDKCENTRAL-COM_T2.ReportProfilesMsgPack.

Some special rules apply:

1. 1. Short-lived profiles shall be processed and added to the list of Active profiles just as the profiles received from Device.X_RDKCENTRAL-COM_T2.ReportProfiles are, except as follows:
      1. 1. No existing, Active profiles shall be automatically deleted if they are not present in the incoming Short-lived profiles
         2. Any Short-lived profile that has the same name as an existing, Active profile, but with a mismatch in hashVersion, shall cause the existing, Active profile to be made inactive and the new, Short-lived profile to go active. Upon reboot, the previous hash version of the profile will go active because it was persisted and the short-lived profile hash was not. Edge case: See Edge Case notes in Description section of this ticket. As described fully in the edge case, if a short-lived profile with an updated hashVersion is received, and the same hashVersion is later received as a normal profile, the older, persisted hashVersion of the profile will go active upon reboot.
         3. Short-lived profiles shall not be persisted across reboot or restart of the T2 component process
         4. Short-lived profiles shall be replaced by any receipt of an Active profile set from Device.X_RDKCENTRAL-COM_T2.ReportProfiles or Device.X_RDKCENTRAL-COM_T2.ReportProfilesMsgPack , for instance during a maintenance window
         5. Other than the exceptions above, Short-lived profiles shall not disrupt the processing of Active profiles.
      2. Short-lived profiles shall remain active according to the configuration of each profile, for instance, generateNow and activationTimeout can cause a profile to be active for some short period of time
   2. T2 Component shall maintain the details of short-lived report profiles received by writing to location /tmp/t2reportprofiles.
      1. Each report profile shall be saved in a separate file with file name indicating the profile name.
      2. Hash value of profile shall be appended to the JSON content of the file.