RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Table of Contents | ||||
---|---|---|---|---|
|
...
Protocol Agents are CCSP components that directly interface to the Cloud. These components facilitate remote administration/management of GW device profiles. The Protocol Agents provides the necessary abstraction to the internal CCSP architecture and internal CCSP components for interacting with the Cloud. The internal CCSP components are not required to be aware of any protocol specific details on the cloud interfaces. As a Protocol Agent could be an SNMP PA or a TR-069 PA..etc.
...
Authenticate and establish secure session with their corresponding cloud configuration server during initialization.
Perform low level protocol handling for downstream traffic.
Perform low level protocol handling for upstream traffic.
Routes cloud messages to internal functional components registered for consumption/processing of those namespaces by looking up the Component Registrar.
“Action” Normalization
Define an XML based Mapping Schema that defines the mapping from external constructs to internal constructs. These constructs will include:Signals errors and routes responses to corresponding cloud adapters
Performs all transactions as an atomic operation.
Manages the order of operations within a transaction and across transactions.
...
Control Plane architecture abstracts the cloud interfaces for internal CCSP architecture. It makes internal common components like TR-069 PA to be agnostic to those cloud interfaces by using a set of normalized actions.
This component is responsible for all normalized actions listed below. This component does not provide interface for servicing normalized actions, rather it depends on functional components to expose APIs on CCSP message bus.
...
...
North bound interface to cloud, this component implements CWMP CPE. Through south bound interface, this component interacts with CR and FCs to perform normalized actions. And the related data structures and function prototypes will be defined by CCSP Architecture Specification, and please refer to it for details. This document only discusses specific items related to the TR-069 PA component.
...
With respect to downloadable applications that define their own data model (defining external data model only), TR-069 PA must be able to route normalized calls to appropriate applications via Application Framework Adapter which should be covered by TR-069 Protocol Agent Software Design Document. The Application Framework Adapter is the default route for all data model namespace for which there is no explicit mapping to an internal namespace.
...
TR-069 PA needs a XML mapping file to achieve the following goals.
...
When PA receives a GetParameterNames request on “Device.” for example, PA through the mapping file and knows the possible sub-systems, and queries local CR to discover all relating FCs that own namespaces under “Device.”. Then PA makes a GetParameterNames normalized action call to each owning FC on local or remote sub-system. After the call returns, PA needs to check each returned namespace against the mapping file to filter out un-supported or invisible ones, and then merge results and sends to cloud server.
...
Per CCSP Architecture specification and CCSP Common Component Design Rules document, we will only define message bus APIs for the following normalized actions.
...
...
For other normalized actions, they will be covered with data model approach. In details, CCSP namespaces are defined for each action. These actions will be requested by PA via setting their values respectively to the namespaces defined. These namespaces are defined in each Functional Component Software Architecture Specification.
CCSP Common Component Design Rules document does not define a specific action and let a FC to do it, the mapping must be included into TR-069 PA namespace mapping file. For action such as Download, depending on our methodology, we may require only single FC to handle all download, or we allow multiple FCs to handle different type of downloads. For latter case, the namespace mapping file must include a mapping entity per download file type. With current CCSP architecture, single functional component will take care of download of all file types. Please refer Secure Software Download Software
...
The following data model related events must be handled by TR-069 PA.
...
In order for TR-069 PA to capture event ValueChanged, TR-069 PA must subscribe to the signal through Component Registrar. And once TR-069 PA receives such event, it needs to check if the value change is caused by itself by checking ‘writeID’ included in the signal against TR-069 PA’s own writeID. If they are same, this signal is simply ignored. Otherwise, PA needs to either notify ACS about a parameter value change in active or passive way as defined by TR-069 specification, or for some special namespaces, PA knows they are asynchronous event indication, could it be TransferComplete, DUStateChangeComplete, or diagnostics completion and so on.
...
...
Component Registration is the same for all common components. We will use whatever defined in CR software design specification to register TR-069 PA and subscribe signals this component wants to capture such as ParameterValueChangeSignal.
...
In case normalized action call on external namespaces that do not have counterpart internal namespaces or say PA cannot get such mapping information from CR, TR-069 PA must be able to route calls to default namespace handler which could be Application Environment Manager through private interface per CCSP Component Registrar specification.
...
Figure 1 shows the overview of TR-069 Protocol Agent.
...
GetParameterNames(“Device.”). PA needs to find out all owning FCs on local and remote sub-systems, and make GetParameterNames normalized action calls. Once it gets results, PA needs to filter out un-supported and invisible namespaces (no matter partial or full names) and send back to ACS.
...
...
...