CDRouter Training Videos

Basic Configuration and Testing

• CDRouter UI Overview As part of our CDRouter training series, Brad gives an overview of the CDRouter user interface and how to add devices, run tests, and view results.

• Basic WAN and LAN test configuration Brad demonstrates how to build a basic configuration for testing, setting up WAN and LAN endpoints.

• Configuring multiple WAN, LAN, and virtual interfaces Brad demonstrates how to set up multiple physical or virtual WAN/LAN interfaces for testing enabled by the CDRouter Multiport expansion.

• Configuring Wireless LAN Interfaces Brad covers specific 802.11 configuration settings for testing over a wireless LAN interface.

• Viewing and Analyzing Results Brad demonstrates what the next steps are once your tests are complete, how to visualize results, and how to restart tests.

• Analyzing Test Log Information Brad shows you how to get insights into your test failures from test logs and packet captures, plus how to export and share results.

• Building a Test Package Brad demonstrates how to select tests, schedule, and launch a test package.

• Managing Devices Under Test Brad covers how to add devices to CDRouter’s device management system to assign configurations, track testing, and connect to a DUT’s user interface from CDRouter’s UI.

• Basic configuration for TR-069 testing Brad shows you how to set up a CDRouter config file for TR-069 testing and how to configure your Device Under Test to connect with CDRouter’s ACS.

• TR-069 test module overview Brad gives an overview of the test packages you can build when performing TR-069 testing.

• Testing performance and stability of Wi-Fi routers and broadband CPE We had a major ISP encounter long-term stability issues in the field that would never be revealed by simply testing throughput in ideal situations. Here’s what happened and how fully-automated stability testing can help.

• Using the CDRouter API with a CI/CD environment Niels demonstrates how to use the cdrouter.py scripts with your CI/CD pipeline.

TR-069 (CWMP) & TR-369 (USP) Data Models

• How do I get USP/TR-369 certified? CDRouter is the official self-test platform of the certification program for TR-369, called BBF.369. Looking to get certified? Reach out to us to get started!

• Navigating Broadband Forum Data Models Intrinsic to the operation of CWMP are the objects and parameters made available to an ACS by a CWMP endpoint. These maps of a CPE’s capabilities and state are referred to as “data models”.

• Looking at Data Models and Objects Every data model in TR-069 contains the objects and parameters that represent the functions of a broadband CPE or other device. This includes their addressable name, syntax, data types, and a normative description of how they are to be used.

• Data Model Parameters Most objects contain a set of elements containing sub-objects and parameters. Parameters are defined using the parameter element, and, like Objects, have a set of attributes and elements that describe how the parameter is to be used and its requirements.

TR-069 (CWMP) Testing

• TR-069 Training - The Inform RPC TR-069 uses several remote procedure calls whose definition determine the types of TR-069 messages that are sent and received by an ACS or CPE. Every RPC is defined in the TR-069 base XML schema which can be found on the Broadband Forum website.

• Overview of a TR-069 Session TR-069 refers to the Technical Report published by the Broadband Forum that defines the CPE WAN Management Protocol, or CWMP. CWMP was developed to allow providers of broadband services to deploy and manage customer premises equipment in home and business networks.

• Event Basics Every TR-069 session is initiated by a CWMP Endpoint on a CPE. These sessions always occur for a specific reason, called an “Event”. All of the Events that have yet to be delivered to the ACS are contained as arguments in the Inform RPC at the start of every TR-069 session.

• ACS Discovery In TR-069, the CPE is always initiates a session. When making first contact with an ACS, how does it know the ACS URL it is supposed to contact?

• Connection Request Basics Though every TR-069 session is initiated by the CPE endpoint, sometimes it’s necessary for the ACS to request that the CPE contact it immediately. To do this, TR-069 defines a Connection Request mechanism in CWMP, which allows the ACS to stimulate the CPE to begin a session.

• XMPP Connection Request Mechanism There’s one caveat to ConnectionRequests - they require that the CPE can be reached by the ACS over HTTP. For endpoints that may reside behind a gateway, this is not the case, thanks to Network Address Translation or Firewall rules.

• XML and SOAP in TR-069 While XML is used most often to define and describe information, TR-069 also uses it directly over the wire when transmitting messages. This means that the ACS and CPE pass XML documents back and forth over HTTP during a TR-069 session.

• Notifications In TR-069, the 4 Value Change event code is used when a parameter set for notification is changed by any mechanism other than the ACS. These conditions are set using the SetParameterAttributes RPC.

• Session Retry Mechanism Every TR-069 session is initiated by a CWMP endpoint that is looking to deliver an event. These events have different delivery requirements, using language such as “must not discard”, “must retry until reboot”, “may retry and “must not retry”.

• TR-069 Training - The GetRPCMethods RPC The GetRPCMethods argument is used by both the CPE and the ACS to request a list of the RPCs supported by either endpoint to better understand the endpoint’s capabilities. It’s one of the simpler RPCs in that it contains no arguments

• TR-069 Training - GetParameterNames and Parameter Paths When an ACS wants to learn what objects exist on a CPE and what parameters they support, it can use the GetParameterNames RPC. Like other RPCs, GetParameterNames makes use of the ParameterPaths argument, so let’s take a minute to understand parameter paths.

• Get/Set Parameter Values and the Status argument The fundamental purpose of TR-069 is to allow an ACS to interact with the CPE’s instantiated data model, that is, the representation of its current state. The RPCs that form the basis of this include the Get and SetParameterValues methods.

• TR-069 Training - Parameter Attributes Every parameter a CPE’s CWMP data model contains metadata known as “attributes”. These attributes include the “Notification” attribute and “AccessList” attribute. The access attribute was defined early on in TR-069 to provide a method for assigning an access control rule identifier to each individual parameter

• AddObject and DeleteObject An “object” in a CPE data model is an element of functionality that can be configured by an ACS. While an object’s parameters are configured using the SetParameterValues RPC, Objects that are able to be created by the ACS can be added to a device using the AddObject RPC, and removed using the DeleteObject RPC.

• Upgrading CPE Firmware with the Download and TransferComplete RPCs Perhaps the biggest use case for TR-069 is managing a CPE’s firmware, allowing service providers to remotely upgrade their install base without needing to send the firmware to the customer or send an engineer.

• Reboot and FactoryReset The Reboot RPC is used by the ACS to explicitly cause the device hardware to restart. This could be for any number of reasons, though should never be used as a means to force the CPE to upgrade itself.

TR-369 (USP)

• Basic USP Configuration Brad goes through the CDRouter configuration steps and builds a test package to test TR-369, the User Services Platform, on your device.

• USP Test Module Overview Brad gives an overview of the different test modules CDRouter contains for USP/TR-369 testing on your device.

• An overview of the User Services Platform (USP/TR-369) USP is a revolutionary standard that builds on the lessons learned from TR-069.

• USP Endpoints There are two kinds of endpoints in USP: Agents, and Controllers. A USP Agent is an Endpoint that exposes functions represented by a set of service elements.

• USP Architecture and Use Cases The User Services Platform is a system for managing, monitoring, deploying, troubleshooting, and controlling any kind of network connected electronics or virtual services.

• USP Data Models The functions of service elements are described in a set of xml documents known as the USP data model. A data model describes how things like network interfaces, device functions, IoT objects, and more are exposed to controllers. You can find the USP data models at:

• Using path names to address service elements Service Elements that are defined in the USP Data Model are addressed in USP Messages with a particular syntax called Path Names. Path Names are called such because they describe the “path” within the data model’s tree of objects used to reference a particular object or elements of that object to operate upon.

• USP Records and USP Messages Communications between a USP Controller and USP Agent are delivered using two separate constructs: the USP Message, and its container, the USP Record.

• The USP Add Message The Add Message in USP is used to create new instances of multi-instance objects in the Agent’s instantiated data model. This is used for a wide variety of service configurations such as creating new Wi-Fi networks.

• Using allow_partial and required_parameter flags There are three USP messages that are used to change the state of an Agent’s service elements: Add, Set, and Delete. Since these messages can be used for a number of different use cases, they contain mechanisms to ensure that the Controller is able to configure service elements

• USP (TR-369) Training Workshop Series Videos The Broadband Forum’s User Services Platform (TR-369) is a revolutionary new standard enabling new markets and revenue streams for service providers, software providers, and consumer electronics manufacturers looking to monetize the connected home.

Miscellaneous

• QA Cafe and RDK-B testing on the RDK Podcast The QA Cafe team works closely with the RDK community to validate the open-source RDK-B solution. Our CTO Tim Winters got a chance to sit down with Jamie Walker from the RDK Podcast to talk about testing, automation, standards, and how CDRouter helps RDK-B implementations stay robust and interoperable! Watch it here.

• Beyond the Phy - Testing Fully-Featured Wi-Fi Products As new 802.11 technologies address coverage and congestion issues, Wi-Fi routers and APs must support a web of configuration and feature options while handling complex applications and networking technologies. Testing and validation of performance, stability, and interoperability are critically important for the success of your products and services.

• Running CDRouter through an access concentrator or shared test setup Brad demonstrates how to set up automated CPE testing when using a GPON OLT, DOCSIS CMTS, or an Amarisoft LTE Callbox.