Cisco OL-27172-01 User Manual

Download

Cisco Broadband Access Center 3.8 Administrator Guide

April 02, 2013

Americas Headquarters

Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000

800 553-NETS (6387)

Fax: 408 527-0883

Text Part Number: OL-27172-01

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Cisco Broadband Access Center 3.8 Administrator Guide

CONTENTS

Preface xv

Audience xv

Organization xvi

Conventions xvii

Product Documentation xviii

Preface

The Cisco Broadband Access Center 3.8 Administrator Guide describes concepts and configurations related to Cisco Broadband Access Center, which is called Cisco BAC throughout this guide.

This chapter provides an outline of the other chapters in this guide, detailed information about related documents that support this Cisco BAC release, and demonstrates the styles and conventions used in the guide.

Note This document is to be used in conjunction with the documentation listed in Product Documentation,

page xviii.

Audience

This chapter contains the following information:

• Audience, page xv

• Organization, page xvi

• Conventions, page xvii

• Product Documentation, page xviii

• Related Documentation, page xviii

• Obtaining Documentation and Submitting a Service Request, page xviii

The Cisco Broadband Access Center 3.8 Administrator Guide is written for system administrators involved in automating large-scale provisioning for broadband access. The network administrator should be familiar with these topics:

• Basic networking concepts and terminology.

• Network administration.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

Organization

This guide includes the following chapters:

Chapter Title Description

Chapter 1 Broadband Access Center Overview Describes Cisco BAC, its features and benefits.

Chapter 2 Broadband Access Center

Chapter 3 Configuration Workflows and

Chapter 4 CPE Management Overview Provides an overview of CPE management and

Chapter 5 Configuration Templates

Chapter 6 Firmware Management Describes the firmware management feature that

Chapter 7 Parameter Dictionaries Describes the use of Parameter Dictionaries.

Chapter 8 CPE History and Troubleshooting Describes how to troubleshoot CPE, using device

Chapter 9 Managing Cisco Broadband Access

Chapter 10 Database Management Describes how to manage and maintain the RDU

Chapter 11 Monitoring Cisco Broadband Access

Chapter 12 Configuring CWMP Service Describes how to configure the CWMP service for

Chapter 13 Configuring CWMP Service Security Describes how to enhance security options using

Chapter 14 CWMP Device Operations Describes the operations that you can perform on

Chapter 15 Understanding the Administrator

Chapter 16 Using the Administrator User

Chapter 17 Configuring Broadband Access

Chapter 18 Scripting Framework Describes DPE scriptable extension framework

Architecture

Checklists

Management

Center

User Interface

Interface

Center

Preface

Describes the systems architecture implemented in this Cisco BAC release.

Provides checklists to follow when configuring Cisco BAC for use.

describes key concepts supported within Cisco BAC.

Describes the configuration templates that Cisco BAC supports, and how to author custom configuration templates.

Cisco BAC supports.

information, made available through Cisco BAC.

Describes the various options that help manage Cisco BAC.

database.

Describes how to monitor the Cisco BAC servers.

use with Cisco BAC.

Cisco BAC.

the device using Cisco BAC.

Describes how to access Cisco BAC using the administrator user interface.

Describes administration activities, including searching for and viewing device information.

Describes the configuration activities that are performed using the Cisco BAC administrator application.

which facilitates creating extension scripts, adding extension scripts in Cisco BAC, and verifying the script status in the DPE.

xvi

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Preface

Conventions

This document uses the following conventions:

Chapter Title Description

Chapter 19 RDU and DPE Connection

Management

Chapter 20 Cisco BAC Support Tools and

Advanced Concepts

Chapter 21 Troubleshooting Broadband Access

Center

Glossary Defines terminology used in this guide and

Describes the RDU TCP connection management, RDU batch concurrency and RDU DPE synchronization.

Describes Cisco BAC tools intended to help configure, maintain speed, and improve the installation, deployment, and use of Cisco BAC.

Describes how to troubleshoot Cisco BAC servers.

generally applicable to the technologies being discussed.

Convention Indication

bold font Commands and keywords and user-entered text appear in bold font.

italic font Document titles, new or emphasized terms, and arguments for which you supply

[ ] Elements in square brackets are optional.

{x | y | z } Required alternative keywords are grouped in braces and separated by

[ x | y | z ] Optional alternative keywords are grouped in brackets and separated by

string A nonquoted set of characters. Do not use quotation marks around the string or

courier font Terminal sessions and information the system displays appear in courier font.

< > Nonprinting characters such as passwords are in angle brackets.

[ ] Default responses to system prompts are in square brackets.

!, # An exclamation point (!) or a pound sign (#) at the beginning of a line of code

Note Means reader take note.

values are in italic font.

vertical bars.

the string will include the quotation marks.

indicates a comment line.

OL-27172-01

Caution Means reader be careful. In this situation, you might perform an action that could result in equipment

damage or loss of data.

Cisco Broadband Access Center 3.8 Administrator Guide

xvii

Product Documentation

Note We sometimes update the printed and electronic documentation after original publication. Therefore,

you should also review the documentation on Cisco.com for any updates.

You can view the marketing and user documents for Cisco Broadband Access Center at:

http://www.cisco.com/en/US/products/sw/netmgtsw/ps529/tsd_products_support_series_home.html

The following document gives you the list of user documents for Cisco Broadband Access Center 3.8:

http://www.cisco.com/en/US/docs/net_mgmt/broadband_access_center/3.8/documentation/overview/ Cisco_BAC38_DocOverview.html

Broadband Access Center Overview

This chapter provides an overview of Cisco Broadband Access Center (Cisco BAC).

Cisco BAC automates the tasks of provisioning and managing customer premises equipment (CPE) in a broadband service provider network.

With the high-performance capabilities of Cisco BAC, you can scale the product to suit networks of virtually any size, even those with millions of CPE. It also offers high availability, made possible by the product’s distributed architecture and centralized management.

Cisco BAC supports provisioning and managing of CPE by using the Broadband Forum’s CPE WAN Management Protocol (CWMP), a standard defined in the TR-069 specification. Cisco BAC integrates the capabilities defined in TR-069 to increase operator efficiency and reduce network-management problems.

Cisco BAC supports devices based on the TR-069, TR-098, TR-104, TR-106, TR-181, and TR-196 standards. These devices include Ethernet and ADSL gateway devices, wireless gateways, VoIP ATAs, and other devices compliant with CWMP. Cisco BAC also provides for runtime-extensible data models to support any upcoming data-model standards or any vendor-specific data models based on CWMP.

Cisco BAC provides such critical features as redundancy and failover. Cisco BAC can be integrated into new or existing environments through the use of a provisioning application programming interface (API) that lets you control how Cisco BAC operates.

You can use the provisioning API to register devices in Cisco BAC, assign device configuration policies, execute any CWMP operations on the CPE, and configure the entire Cisco BAC provisioning system.

This chapter includes the following sections:

• Features and Benefits, page 1-1

• Supported Technology, page 1-3

Features and Benefits

Cisco BAC helps service providers provision and manage the rapidly expanding number of home networking devices.

Cisco BAC supports mass-scale provisioning and managing of Femtocell Access Point (FAP) devices that function as mini 3G cell tower in customer premises and backhaul call using the customer’s internet connection. Apart from supporting the FAP devices, Cisco BAC also supports provisioning and managing of Digital Life Controller (DLC) devices based on TR-069 protocol.

This section describes the basic features and benefits that the Cisco BAC architecture offers:

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

1-1

Features and Benefits

Chapter 1 Broadband Access Center Overview

• Configuration management: Vastly simplified in Cisco BAC through configuration templates, which

provide an easy, yet flexible mechanism to assign configurations for CPE. You can use the template-processing mechanism to customize configurations for millions of devices by using a small number of templates.

By using these XML-based templates, you can set configuration parameters and values, and notification and access controls on a device. Configuration templates allow:

–

Conditionals, to include or exclude sections of a template based on, among others, Cisco BAC property values.

–

Includes, to include template content from other files.

–

Parameter substitution, to substitute Cisco BAC property values into template parameters.

–

Prerequisites, to evaluate whether the template is applicable to a device at given time.

• Firmware management: Maintaining and distributing sets of firmware image files to corresponding

CPE through the Cisco BAC system. A firmware rules template, associates the firmware image files to groups of devices. Cisco BAC uses the rules in the associated firmware rules template to evaluate the firmware that is downloaded to the device.

Using the firmware management feature, you can view firmware information on devices, add firmware images to the database, and apply the image files to specific CPE.

• Massive scalability: Enhanced by partitioning CPE into provisioning groups; each provisioning

group is responsible for only a subset of the CPE. A provisioning group is designed to be a logical (typically geographic) grouping of servers, usually consisting of one or more Device Provisioning Engines (DPEs).

A single provisioning group can handle the provisioning needs of up to 500,000 devices. As the number of devices grows past 500,000, you can add additional provisioning groups to the deployment.

• Standards-based security: Cisco BAC is designed to provide a high degree of security by using

CWMP, outlined in the TR-069 standard. The CWMP security model is also designed to be scalable. It is intended to allow basic security to accommodate less robust CPE implementations, while allowing greater security for those that can support more advanced security mechanisms.

Cisco BAC integrates the Secure Sockets Layer (SSL) version 3.0 and the Transport Layer Security (TLS) version 1.0 protocols into its CWMP ACS implementation. By using HTTP over SSL/TLS (also known as HTTPS), Cisco BAC provides confidentiality and data integrity, and allows certificate-based authentication between the various components.

• Easy integration with back-end systems, using Cisco BAC mechanisms such as:

–

The Cisco BAC Java API, which can be used to perform all provisioning and management operations.

–

The Cisco BAC publishing extensions, which are useful in writing RDU data into another database.

–

The Cisco BAC Data Export tool, with which you can write device information from the Cisco BAC system to a file.

1-2

–

The SNMP agent, which simplifies integration for monitoring Cisco BAC.

–

The DPE command line interface, which simplifies local configuration when you use it to copy and paste commands.

• Extensive server management: Cisco BAC provides extensive server performance statistics, thereby

enabling monitoring and troubleshooting.

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 1 Broadband Access Center Overview

• Device diagnostics and troubleshooting: You use this feature to focus on a single device and collect

diagnostics information for further analysis. Cisco BAC provides several features to assist diagnosis:

–

Device history—Provides a detailed history of significant events that occur in a device provisioning lifecycle.

–

Device faults—Detects devices with recurring faults, which can cause bottlenecks and affect network performance.

–

Device troubleshooting—Provides detailed records of device interactions with Cisco BAC servers for a set of devices that are designated for such troubleshooting.

–

Direct device operations—Operations such as IP Ping and Get Live Data can be run on the device for more insight.

• Multi-instance object support: This feature introduces support for discovering and updating the CPE

parameters associated with multiple object instances, without specifying the actual instance number. The multi-instance object support in the template, adds the flexibility to apply the configuration on selective object instances.

• Scriptable framework: This feature introduces the scriptable extension service which facilitates

running the Java scripts based DPE extensions. This feature also provides the support to load and unload the extensions dynamically without restarting the DPE.

Supported Technology

This Cisco BAC release supports the provisioning and managing of CPE only through CWMP, outlined in the TR-069 specification. However, virtually any data models based on TR-069, TR-098, TR-104, TR-106, TR-181, and TR-196 extensions are supported.

CWMP Technology

TR-069 is a standard for remote management of CPE. This standard defines CWMP, which enables communication between CPE and an autoconfiguration server (ACS).

CWMP details a mechanism that increases operator efficiency and reduces network management problems through its primary capabilities. These capabilities include:

• Autoconfiguration

• Firmware Management

• Status and Performance Monitoring

• Device Diagnostics and Troubleshooting

In addition to CWMP, the TR-069 specification defined a version 1.0 of the data model for Internet Gateway Device (IGD), which has since been expanded by TR-098. CWMP, as defined in TR-069, works with any data model extended from CWMP, including those defined in TR-098, TR-104, TR-106, TR-181, and TR-196, upcoming new ones, or those that are vendor specific.

TR-196

OL-27172-01

TR-196 standard provides the data model for the Femto Access Point (FAP) for remote management purposes using the TR-069 CWMP.

Cisco Broadband Access Center 3.8 Administrator Guide

1-3

Supported Technology

Chapter 1 Broadband Access Center Overview

The Cisco BAC template-based mechanism to assign configurations for devices is enhanced to support the TR-196 devices in the service provider's network. Cisco BAC provides two additional parameter dictionary files to support the following TR-196 data models:

• TR-196 Amendment 1

• TR-196 Issue 2 and TR-181 Issue 2 Amendment 2

Cisco BAC also provides a Generally Available (GA) scriptable extensions targeting residential 3G features of above TR-196 data models. You can use the corresponding properties to configure the extension and the TR-196 data model to be used for any device.

The support for discovering multiple objects instances associated with a parameter, is also available for TR-196 devices.

1-4

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Broadband Access Center Architecture

This chapter describes the system architecture implemented in this Cisco Broadband Access Center (Cisco BAC) release.

This chapter includes the following sections:

• Cisco BAC Deployment, page 2-1

• Architecture, page 2-2

Cisco BAC Deployment

Cisco BAC provisions devices are based on the TR-069, TR-098, TR-104, TR-106, TR-181, and TR-196 standards. This includes Ethernet and ADSL gateway devices, wireless gateways, VoIP ATAs, and other devices compliant with the CPE WAN Management Protocol (CWMP).

Figure 2-1 represents a typical, fully redundant, CWMP deployment in a Cisco BAC network.

CHAP T ER

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

2-1

Architecture

Operations

Support

Systems

Redundant

BAC RDU

Server

Central Location

Access

Network

284384

Target

Subscriber

Provisioning Group 1

BAC DPE

Servers

CAR RADIUS

Servers

CNR DHCP

Servers

Load

Balancer

STUN

Server

Provisioning Group [n]

BAC DPE

Servers

CAR RADIUS

Servers

CNR DHCP

Servers

Load

Balancer

CHMS Server

Chapter 2 Broadband Access Center Architecture

Figure 2-1 CWMP Deployment in Cisco BAC

Architecture

This section describes the basic Cisco BAC architecture including:

Cisco Broadband Access Center 3.8 Administrator Guide

2-2

• Regional Distribution Unit (RDU) that provides:

–

The authoritative data store of the Cisco BAC system.

–

Support for processing application programming interface (API) requests.

–

Monitoring of the system’s overall status and health.

See Regional Distribution Unit, page 2-4, for additional information.

• Device Provisioning Engines (DPEs) that provide:

–

Interface with customer premises equipment (CPE).

–

Configuration and firmware policy instructions cache.

–

Autonomous operation from the RDU and other DPEs.

–

CPE WAN Management Protocol (CWMP) service.

–

IOS-like command line interface (CLI) for configuration.

–

Hypertext Transfer Protocol (HTTP) file service.

See Device Provisioning Engines, page 2-4, for additional information.

OL-27172-01

Chapter 2 Broadband Access Center Architecture

• STUN server:

–

Supports a UDP based connection request mechanism defined in TR069 Annex G to allow Cisco BAC to initiate a session with a CPE that is operating behind a NAT Gateway.

• Cisco Management Heartbeat Server (CMHS) server:

–

A new connection request method that allows Cisco BAC to send connection requests to DLC devices through the CMHS server, using BAC north bound API interfaces or BAC Admin UI.

• Client API that provides total client control over the system’s capabilities.

• Provisioning Groups that provide:

–

Logical grouping of DPE servers, CAR-RADIUS servers and CNR-DHCP servers in a redundant cluster.

–

Redundancy and scalability

See Provisioning Groups, page 2-6, for additional information.

• The Cisco BAC process watchdog that provides:

–

Administrative monitoring of all critical Cisco BAC processes.

–

Automated process restart capability.

–

Ability to start and stop Cisco BAC component processes.

–

Ability to send the SNMP trap if any BAC process fails to start or stop, or stops unexpectedly. SNMP trap is a mechanism that the trap receiver uses to get the information about the process or component failure. A SNMP trap is also sent if Cisco BAC process watchdog fails to start on any of the servers that run Cisco BAC components. Cisco BAC process watchdog reports all the critical conditions of BAC components through SNMP trap.

Architecture

See Cisco BAC Process Watchdog, page 2-7, for additional information.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

2-3

Architecture

Chapter 2 Broadband Access Center Architecture

• An administrator user interface that provides:

–

Support for adding, deleting, and modifying CWMP devices; searching for devices, retrieving device details, and running device operations.

–

Support for configuring global defaults and defining custom properties.

–

Ability to view additional performance statistics.

–

Management of firmware rules and configuration templates.

See Administrator User Interface, page 9-4, for additional information.

• An SNMP agent that supports:

–

Third-party management systems.

–

SNMP version v2.

–

SNMP Notification.

See SNMP Agent, page 2-7, for additional information.

• Cisco Network Registrar servers that provide:

–

Dynamic Host Configuration Protocol (DHCP).

See Cisco Network Registrar, page 2-8, for additional information.

Regional Distribution Unit

The Regional Distribution Unit (RDU) is the primary server in the Cisco BAC provisioning system. It is installed on a server running the Solaris 10 or Linux 5.x operating system.

The functions of the RDU include:

• Managing preprovisioned and discovered data from devices.

• Generating instructions for DPEs and distributing them to DPE servers for caching.

• Cooperating with DPEs to keep them up to date.

• Processing API requests for all Cisco BAC functions.

• Managing the Cisco BAC system.

The RDU supports the addition of new technologies and services through an extensible architecture.

Cisco BAC currently supports one RDU per installation. Use of clustering software from Veritas or Sun is recommended for providing RDU failover. Use of RAID (Redundant Array of Independent Disks) shared storage is recommended in such a setup.

Device Provisioning Engines

The Device Provisioning Engine (DPE) communicates with the CPE on behalf of the RDU to perform provisioning or management functions.

The RDU generates instructions that the DPE must perform on the device. These instructions are distributed to the relevant DPE servers, where they are cached. These instructions are then used during interactions with the CPE to perform tasks, such as configuration of devices, firmware upgrades, and data retrieval.

Each DPE caches information for up to 500,000 devices, and multiple DPEs can be used to ensure redundancy and scalability.

2-4

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 2 Broadband Access Center Architecture

The DPE manages these activities:

• Synchronization with RDU to retrieve the latest set of instructions for caching.

• Communication with CPE using HTTP and HTTPS for file download service.

• Authentication and encryption of communication with CPE.

• Authenticate and Authorize CPE by processing the request from RADIUS server.

The DPE is installed on a server that is running the Solaris 10 or Linux 5.x operating system. The DPE is configured and managed by using the CLI, which you can access locally or remotely using Telnet. See the Cisco Broadband Access Center 3.8 DPE CLI Reference, for specific information on the CLI commands that a DPE supports.

See these sections for other important information:

• DPE Licensing, page 2-5

• DPE-RDU Synchronization, page 19-3

Also, familiarize yourself with the concept of instruction generation, which is described in Instruction

Generation and Processing, page 4-14.

Architecture

DPE Extension

DPE Licensing

Note For licensing purposes, a registered DPE is considered to be one node.

The DPE extension interface provides several levels of extensibility that range from ability to make minor changes to existing behavior via an extension to a complete overhaul of DPE behavior that allows it to perform any logic with HTTP or CWMP. It can even function independent of the RDU. The DPE extension simply augments the existing CWMP behavior.

However, when DPE is extended in such a way that RDU is either not required or is not used to store all device records, alternative licensing is needed. The Feature Pack licensing feature, described in DPE

Licensing, page 2-5, provides the alternative licenses.

Licensing controls the number of DPEs (nodes) that you can use. If you attempt to install more DPEs than you are licensed to have, those new DPEs will not be able to register with the RDU, and will be rejected. Existing licensed DPEs remain online.

Whenever you change licenses, by adding a license, extending an evaluation license, or through the expiration of an evaluation license, the changes take immediate effect.

When you delete a registered DPE from the RDU database, a license is freed. Since the DPEs automatically register with the RDU, you must take the DPE offline if the intention is to free-up the license. Then, delete the DPE from the RDU database by using the RDU administrator user interface.

OL-27172-01

Note The functions enabled using a specific license, continue to operate even when the corresponding license

is deleted from the system.

Cisco Broadband Access Center 3.8 Administrator Guide

2-5

Architecture

Cisco BAC now provides a mechanism to license DPE extension feature packs. The feature pack licenses indicate the count of the devices that can be processed by the feature pack extension. The feature pack licenses can be added to the RDU through Cisco BAC admin UI or API independently with or without CWMP / DPE licenses.

DPEs that are rejected during registration because of licensing constraints, do not appear in the administrator user interface. To determine the license state, you need to examine the log files of the RDU and the DPE.

Provisioning Groups

A provisioning group is designed to be a logical (typically geographic) grouping of servers that usually consist of one or more DPEs, CNR-DHCP servers and CAR-RADIUS servers. Each DPE in a given provisioning group, caches identical sets of instructions from the RDU; thus enabling redundancy and load balancing.

A single provisioning group can handle the provisioning needs of up to 500,000 devices. As the number of devices grows past 500,000, you can add additional provisioning groups to the deployment.

Chapter 2 Broadband Access Center Architecture

Note The servers for a provisioning group are not required to reside at a regional location, they can just as

easily be deployed in the central network operations center.

For more information, see:

• Discovery of ACS URL, page 2-6

• Provisioning Group Scalability, page 2-7

Discovery of ACS URL

In the distributed architecture that Cisco BAC provides, the RDU is the centralized aggregation point that never directly interacts with a CPE. Any required interactions with the CPE are delegated to the provisioning group.

Each device identifies the provisioning group to which it connects by the URL of a single autoconfiguration server (ACS); in other words, the DPE. Until the URL is updated, the device contacts the DPE at the same URL.

All redundant DPEs in a given provisioning group, must share a single ACS URL. The RDU has to be aware of the URL that is associated with each provisioning group and, by extension, of all DPEs in that provisioning group. The RDU uses its knowledge of the provisioning group’s ACS URL to redirect devices to a new provisioning group, when required.

The RDU automatically learns the provisioning group’s ACS URL from DPE registrations; or the ACS URL is configured on the provisioning group object, using the API or the administrator user interface. For information on configuring the ACS URL, see Provisioning Group Configuration Workflow,

page 3-8.

The CPE can determine the ACS (DPE) URL in one of two ways:

• By preconfiguring the URL on the device. This ACS URL is the configured URL of the Cisco BAC

server that is associated with each provisioning group. The URL is preconfigured on the device before it is shipped to the customer, and is also known as the assigned URL.

2-6

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 2 Broadband Access Center Architecture

• By discovering the URL via DHCP. This ACS URL is returned in response to a DHCP Discover, a

DHCP Request, or a DHCP Inform. This mechanism is limited to deployments of primary Internet gateway devices, because it requires the ability to make DHCP requests to the WAN side.

Note Assigning a URL using preconfiguration is a more secure mechanism than one discovered

using DHCP.

Provisioning Group Scalability

Provisioning groups enhance the scalability of the Cisco BAC network by making each provisioning group responsible for only a subset of devices. This partitioning of devices can be along regional groupings or any other policy that the service provider defines. When the size of the provisioning group is restricted, the DPEs can be more effective in caching the necessary information.

To scale a deployment, the service provider can:

• Upgrade existing DPE server hardware.

• Add DPE servers to a provisioning group.

Architecture

• Add provisioning groups.

Cisco BAC Process Watchdog

The Cisco BAC process watchdog is an administrative agent that monitors the runtime health of all Cisco BAC processes. This watchdog process ensures that if a process stops unexpectedly, it is automatically restarted.

The Cisco BAC process watchdog can be used as a command line tool to start, stop, restart, and determine the status of any monitored processes.

See Cisco BAC Process Watchdog, page 9-1, for additional information on how to manage the monitored processes.

SNMP Agent

Cisco BAC provides basic SNMP v2-based monitoring of the RDU and the DPE servers. The Cisco BAC SNMP agents support SNMP informs and traps. You can configure the SNMP agent on the DPE by using snmp-server CLI commands, and on the RDU by using the SNMP configuration command-line tool.

See Monitoring Servers by Using SNMP, page 11-5, for additional information on the SNMP configuration command line tool, and the Cisco Broadband Access Center 3.8 DPE CLI Reference, for additional information on the DPE CLI.

Logging

OL-27172-01

Logging of events is performed at the DPE and the RDU. In some unique situations, DPE events are additionally logged at the RDU to give them higher visibility. Log files are located in their own log directories and can be examined by using any text processor.

Cisco Broadband Access Center 3.8 Administrator Guide

2-7

Architecture

You can compress the files for easier e-mailing to the Cisco Technical Assistance Center or system integrators for troubleshooting and fault resolution. You can also access the RDU and the DPE logs from the administrator user interface.

For detailed information on log levels and structures, and how log files are numbered and rotated, see

Logging, page 21-2.

Access Registrar

CAR is a RADIUS (Remote Authentication Dial-In User Service) server that enables multiple dial-in Network Access Server (NAS) devices to share a common authentication, authorization, and accounting database.

For additional information on Access Registrar, see the User Guide for Cisco Access Registrar 5.0 and

Installation Guide for Cisco Access Registrar 5.0.

RADIUS

Chapter 2 Broadband Access Center Architecture

CAR is based on a client/server model, which supports AAA (authentication, authorization, and accounting). The client is the Network Access Server (NAS) and the server is CAR. The client passes user information onto the RADIUS server and acts on the response it receives.

The server, on the other hand, is responsible for receiving user access requests, authenticating and authorizing users, and returning all necessary configuration information that the client can then pass on to the user.

Cisco BAC now supports RADIUS for device authentication. CAR provides an extension mechanism to allow customization of RADIUS requests and responses. Cisco BAC handles the Authentication and Authorization request through this extension.

Cisco Network Registrar

Cisco Network Registrar provides the DHCP functionality in Cisco BAC. The DHCP extension points on Network Registrar integrate Cisco BAC with Network Registrar. Using these extensions, the CNR registers itself with Cisco BAC.

Note Cisco Network Registrar (CNR) is re-branded to Cisco Prime Network Registrar starting with the 8.0

release.

For additional information on Cisco Prime Network Registrar, see the Cisco Prime Network Registrar

8.1 User Guide, Cisco Prime Network Registrar 8.1 CLI Reference Guide, and Cisco Prime Network Registrar 8.1 Installation Guide.

DHCP

2-8

The DHCP server automates the process of configuring IP addresses on IP networks. The protocol performs many of the functions that a system administrator carries out when connecting a device to a network. DHCP automatically manages network-policy decisions and eliminates the need for manual configuration. This feature adds flexibility, mobility, and control to networked device configurations.

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 2 Broadband Access Center Architecture

LeaseQuery

The LeaseQuery feature allows you to request lease information from the Network Registrar DHCP servers. In this release, the LeaseQuery feature is being used by Connection Request and Femto Authorization Service.

The Connection Request performs the LeaseQuery by providing the list of DHCP servers, whereas the Femto Authorization Service performs the LeaseQuery, using the provisioning group. In case of Femto Authorization Service, the DPE sends DHCP LeaseQuery messages only to the DHCP servers registered for the device's provisioning group, which prevents querying all DHCP servers in the network.

Among all responses, the response from the server that last communicated with the devices, is taken as the authoritative answer.

In earlier Cisco BAC versions, the LeaseQuery feature relied on the operating system to select the source interface and the source port for sending LeaseQuery requests. In this release, you can configure the RDU to use a specific interface and source port.

For detailed information on configuring LeaseQuery in this Cisco BAC release, see Configuring Lease

Query, page 17-27.

Architecture

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

2-9

Architecture

Chapter 2 Broadband Access Center Architecture

2-10

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Configuration Workflows and Checklists

This chapter is divided into two major sections that define the processes to follow when configuring Cisco Broadband Access Center (Cisco BAC) components to support various technologies.

This chapter includes the following sections:

• Component Workflows, page 3-1

• Technology Workflows, page 3-3

Component Workflows

This section describes the workflows you must follow to configure each Cisco BAC component for the technologies supported by Cisco BAC. These configuration tasks are performed before configuring Cisco BAC to support specific technologies.

The component workflows described in this section are arranged in a checklist format and include:

CHAP T ER

RDU Checklist

• RDU Checklist

• DPE Checklist

Table 3- 1 identifies the workflow to follow when configuring the RDU.

Table 3-1 RDU Workflow Checklist

Procedure Refer to...

1. Configure the system syslog service for use with

Cisco BAC.

2. Access the Cisco BAC administrator user interface. Configuring the Administrator User

3. Change the admin password. Configuring the Administrator User

4. Add the appropriate license keys. Managing License Keys, page 17-20

Installation Guide for Cisco Broadband Access Center 3.8

Interface, page 15-1

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

3-1

Component Workflows

DPE Checklist

Note Items marked with an asterisk (*) are mandatory tasks or procedures.

Chapter 3 Configuration Workflows and Checklists

Table 3-1 RDU Workflow Checklist (continued)

Procedure Refer to...

5. Configure the RDU database backup procedure. Backup and Recovery, page 10-4

6. Configure the RDU SNMP agent. Using the snmpAgentCfgUtil.sh

Tool, page 11-6

You must perform the tasks described in Ta b le 3-2 after those described in Ta ble 3 -1 .

Table 3-2 DPE Configuration Checklist

Procedure Refer to ...

1. Configure the system syslog service for use

with Cisco BAC.

2. Change the passwords.* The password command described in the Cisco

3. Configure the provisioning interface. The interface ethernet [intf0 | intf1] command

4. Configure the Cisco BAC shared secret.* The dpe shared-secret command described in the

5. Configure the DPE to connect to the desired

RDU.*

6. Configure the network time protocol (NTP). Solaris or Linux documentation for configuration

7. Configure the provisioning group name.* The dpe provisioning-group primary command

8. Configure the required routes to the RDU as

well as to the devices in the network.

9. Configure the DPE SNMP agent. The SNMP agent commands in the Cisco

Note You can configure the SNMP agent using either the DPE command line interface or the

snmpAgentCfgUtil.sh tool. For more information, see Using the snmpAgentCfgUtil.sh Tool,

page 11-6.

Cisco Broadband Access Center 3.8 Installation Guide.

Broadband Access Center 3.8 DPE CLI Reference.

described in the Cisco Broadband Access Center

3.8 DPE CLI Reference.

Cisco Broadband Access Center 3.8 DPE CLI Reference.

The dpe rdu-server command described in the

Cisco Broadband Access Center 3.8 DPE CLI Reference.

information.

described in the Cisco Broadband Access Center

3.8 DPE CLI Reference.

Solaris or Linux documentation for configuration information.

Broadband Access Center 3.8 DPE CLI Reference.

3-2

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 3 Configuration Workflows and Checklists

Table 3-2 DPE Configuration Checklist (continued)

Procedure Refer to ...

10. Verify that the DPE successfully connected to

the RDU and was registered.

11. Configure the home provisioning group

redirection service on the DPE

Technology Workflows

This section describes the tasks that you must perform when configuring Cisco BAC to support specific technologies; in this case, CWMP. These configuration tasks are performed after configuring Cisco BAC components.

The CWMP technology workflows described in this section are arranged in a checklist format and include:

Technology Workflows

Viewing Servers, page 16-22

The interface ip x.x.x.x. pg-communication and service cwmp-redirect 1 enable commands described in the Cisco Broadband Access Center

3.8 DPE CLI Reference.

• RDU Configuration Workflow, page 3-3

• DPE Configuration Workflow, page 3-5

RDU Configuration Workflow

Table 3- 3 identifies the configuration tasks you must perform to configure the RDU for the CWMP

technology.

Table 3-3 RDU Configuration Workflow

Procedure Refer to ...

1. Create service profiles by using the Cisco BAC

Class of Service.

Define custom properties referenced in templates from the administrator user interface. The custom properties can be referenced in configuration and firmware rules templates.

For each service, you must:

a. Create a configuration template.

Add the configuration template to the RDU from the administrator user interface.

b. Create a firmware rules template.

–

Add the firmware images to the RDU from the administrator user interface.

Configuring Custom Properties, page 17-5

Adding Files, page 17-17

OL-27172-01

–

Add the firmware rules template to the RDU from the administrator user interface.

Cisco Broadband Access Center 3.8 Administrator Guide

3-3

Technology Workflows

Chapter 3 Configuration Workflows and Checklists

Table 3-3 RDU Configuration Workflow (continued)

Procedure Refer to ...

c. Create a Class of Service from the

administrator user interface.

Remember to:

–

Specify the configuration template file.

–

Specify the firmware rules file.

–

Optionally, specify properties.

2. Configure default settings for the CWMP

technology from the administrator user interface.

–

Set the default Class of Service; for example, for unknown devices.

–

Set the Connection Request Service defaults from any of the following pages:

Configuration > Class of Service; Configuration > Defaults; and Devices.

3. Preregister the CWMP devices. Preregistering Device Data in Cisco BAC,

Configuring the Class of Service, page 17-1

Configuring Defaults, page 17-6

page 3-4

Preregistering Device Data in Cisco BAC

Preregistering adds the device record to the RDU before the device makes initial contact with the DPE. The DPE is also known as the autoconfiguration server (ACS). This task is typically executed from the provisioning API. However, you can preregister device data from the administrator user interface as well.

To preregister device data in Cisco BAC:

Step 1 Add the device record to the RDU database by using the API or the administrator user interface.

To add a device record from the administrator user interface:

a. Choose Devices > Manage Devices.

b. On the Manage Devices page, click Add.

The Add Device page appears.

c. Enter values in the appropriate fields. The required and recommended provisioning attributes for a

preregistered device are:

Required

• Device identifier

• Registered Class of Service

• Home provisioning group

Additional Typical Attributes

Additional attributes may be required depending on customer premises equipment (CPE) authentication methods.

3-4

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 3 Configuration Workflows and Checklists

• Owner identifier

• CPE password, if client authentication using unique client certificates is not enabled.

• Connection Request username. This step is optional.

• Connection Request password. This step is optional.

Optional

Connection Request Methods on the Class of Service. This step is optional.

Configuring the connection request method enables device authentication of the autoconfiguration server. Choose from:

• Discovered

• Use FQDN

• Use IP

Step 2 Verify whether the device record is preregistered. To do this:

• Examine the Device Details. To do this:

From the Devices > Manage Devices page, click the View Details icon ( ) corresponding to the device. From the Device Details page:

–

Check if the device settings are correct.

Technology Workflows

–

Look for discovered parameters; these parameters are not displayed if the device is yet to initiate its first contact with the DPE.

–

Check the Device History log.

• Examine the RDU and the DPE log files (see Logging, page 21-2).

Step 3 Configure the device to send periodic informs to the DPE. To do this, set the PeriodicInformEnable and

the PeriodicInformInterval variables in a configuration template.

Step 4 Initiate device contact with Cisco BAC for the first time. To initiate device contact, do one of the

following:

• Initiate a connection request from the API.

• Wait for the next periodic contact from the device.

• Reboot.

Step 5 Verify the first device contact with Cisco BAC. From Device > Manage Devices > Device Details, check

if discovered properties are visible. Also, check the history log for details.

DPE Configuration Workflow

This section describes how you can provide CWMP support at the DPE, by configuring:

• CWMP services for CWMP management on the DPE.

OL-27172-01

See Configuring CWMP Service on the DPE, page 3-6.

• HTTP file services for firmware management on the DPE.

See Configuring HTTP File Service on the DPE, page 3-7.

• Configuring HTTP auth service on DPE.

Cisco Broadband Access Center 3.8 Administrator Guide

3-5

Technology Workflows

Configuring CWMP Service on the DPE

Table 3- 4 identifies the configuration tasks that you must perform to configure the CWMP services on

the DPE.

Table 3-4 DPE Configuration Workflow - CWMP Management

Procedure Refer to ...

Configure the CWMP services that run on the DPE.

Configuring the CWMP technology on the DPE requires that you enable at least one CWMP service. To enable a CWMP service, enter:

service cwmp num enable true

where num identifies the CWMP service, which could be 1 or 2.

By default, the CWMP service is:

–

Enabled on service 1.

–

Disabled on service 2.

1. Configure the port on which the CWMP service

communicates with the CPE.

By default, the CWMP service is configured to listen on:

Chapter 3 Configuration Workflows and Checklists

The CWMP Technology Commands described in the Cisco Broadband Access Center 3.8 DPE

CLI Reference.

The service cwmp num port port command described in the Cisco Broadband Access Center

3.8 DPE CLI Reference.

–

Port 7547 for service 1.

–

Port 7548 for service 2.

2. Configure client authentication for the CWMP

service.

To limit security risks during client authentication, we recommend using the Digest mode (the default configuration).

You should not allow client authentication in the Basic mode, or altogether disable Basic and Digest authentication.

3. Configure client authentication using

certificates through SSL for the CWMP service.

4. Configure the DPE to request configuration

from the RDU for devices unknown to the DPE.

Enabling this feature may allow a Denial of Service attack on the RDU.

The service cwmp num client-auth mode command described in the Cisco Broadband

Access Center 3.8 DPE CLI Reference.

The service cwmp num ssl client-auth mode command described in the Cisco Broadband

Access Center 3.8 DPE CLI Reference.

The service cwmp num allow-unknown-cpe command described in the Cisco Broadband

Access Center 3.8 DPE CLI Reference.

3-6

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 3 Configuration Workflows and Checklists

Configuring HTTP File Service on the DPE

Table 3- 5 identifies the configuration tasks that you must perform to configure the HTTP file services

running on the DPE.

Table 3-5 DPE Configuration Workflow - Firmware Management

Procedure Refer to ...

Configure the HTTP file service that runs on the DPE.

Configuring firmware management on the DPE requires that you enable at least one HTTP file service. To enable a HTTP file service, enter:

service http num enable true

where num identifies the HTTP file service, which could be 1 or 2.

By default, the HTTP service is:

–

Enabled on service 1.

–

Disabled on service 2.

1. Configure the port on which the HTTP file

service communicates with the CPE.

By default, the HTTP file service is configured to listen on:

Technology Workflows

The CWMP Technology Commands described in the Cisco Broadband Access Center 3.8 DPE

CLI Reference.

The service http num port port command described in the Cisco Broadband Access Center

3.8 DPE CLI Reference.

–

Port 7549 for service 1.

–

Port 7550 for service 2.

2. Configure client authentication for the HTTP

file service.

To limit security risks during client authentication, we recommend that you use the Digest mode (the default configuration).

You should not allow client authentication in the Basic mode, or altogether disable Basic and Digest authentication.

3. Configure client authentication by using

certificates through SSL for the HTTP file service.

The service http num client-auth mode command described in the Cisco Broadband

Access Center 3.8 DPE CLI Reference.

The service http num ssl client-auth mode described in the Cisco Broadband Access Center

3.8 DPE CLI Reference.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

3-7

Technology Workflows

Configuring HTTP Auth Service on the DPE

Table 3- 6 below identifies the configuration tasks that you must perform to configure the AUTH services

on the DPE.

Table 3-6 DPE Configuration Workflow - AUTH Management

Procedure Refer to ...

Configure the Auth service that run on the DPE.

To enable a Auth service, enter:

service auth 1 enabled true

By default, the Auth service is enabled.

Configure the http interface on which the Auth service is running on.

To configure the Auth service interface, enter:

service auth 1 address (host_fqdn)

By default, the Auth service is configured to listen on

localhost.

Configure the port on which the Auth service communicates with the CAR-EP.

To configure the Auth service port, enter:

service auth 1 port port_num

By default, the Auth service is configured to listen on

7551.

Enables or disables use of HTTP over SSL/TLS for the Auth service.

To enable SSL/TLS for the Auth Service interface, enter:

service auth 1 ssl enabled true

Chapter 3 Configuration Workflows and Checklists

The CWMP Technology Commands described in the Cisco Broadband Access Center 3.8 DPE

CLI Reference.

The service http num port port command described in the Cisco Broadband Access Center

3.8 DPE CLI Reference.

The service http num client-auth mode command described in the Cisco Broadband

Access Center 3.8 DPE CLI Reference.

The service http num ssl client-auth mode described in the Cisco Broadband Access Center

3.8 DPE CLI Reference.

Provisioning Group Configuration Workflow

Provisioning groups are automatically created when the DPE is first configured to be in a particular provisioning group (see Adding DPE to a Provisioning Group, page 12-18), and then it registers with the RDU. After the provisioning group is created, you can configure it by assigning the URL of the Cisco BAC server from the administrator user interface.

Before configuring the provisioning group URL, familiarize yourself with Cisco BAC concepts regarding local and regional redundancy. These concepts are described in Provisioning Group Scalability

and Failover, page 12-16.

Note We recommend that you assign a URL to the provisioning group right when you create the provisioning

group. Assigning the URL enables CPE redirection between provisioning groups. If you are using a load balancer, ensure that the address of the load balancer is used as the ACS URL.

Cisco Broadband Access Center 3.8 Administrator Guide

3-8

OL-27172-01

Chapter 3 Configuration Workflows and Checklists

To configure the ACS URL of a provisioning group from the administrator user interface:

Step 1 On the primary navigation bar, click Servers > Provisioning Groups.

The Manage Provisioning Groups page appears.

Step 2 Click the identifier link of the correct provisioning group.

The View Provisioning Group Details page appears.

Step 3 In the Provisioning Group Properties area, enter the URL in the ACS URL field.

Note Remember that the URL that you configure overrides the discovered ACS URL.

Step 4 Click Submit.

The provisioning group now contacts Cisco BAC at the URL that you configured.

Configuring Home Provisioning Group Redirection Service on the DPE

Technology Workflows

Cisco BAC provides redirection to the home provisioning group of a device by having the provisioning groups communicate among themselves (see Redirecting CPE to Home Provisioning Group, page 14-7).

To enable the home provisioning group redirection feature, you must configure the home provisioning group redirection service on the DPE.

Table 3- 7 identifies the configuration tasks that you must perform to configure the home provisioning

group redirection service on the DPE.

Table 3-7 Home Provisioning Group Redirection Configuration

Procedure Refer to...

1. Configure the DPE to use the interface

identified by the IP address for communication with other provisioning groups.

The interface ip x.x.x.x. pg-communication command described in the Cisco Broadband

Access Center 3.8 DPE CLI Reference.

If you do not configure the DPE to use this interface, the DPE always binds to the localhost.

2. Configure the cwmp-redirect service on the

DPE.

To enable the cwmp-redirect service, enter:

service cwmp-redirect 1 enable true

The service cwmp-redirect 1 enable command described in the Cisco Broadband Access Center

3.8 DPE CLI Reference

For information on CLI commands used for the cwmp-redirect service, see the Cisco Broadband

Access Center 3.8 DPE CLI Reference.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

3-9

Technology Workflows

Chapter 3 Configuration Workflows and Checklists

3-10

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

CHAP T ER

CPE Management Overview

This chapter describes the management of customer premises equipment (CPE) by using the CPE WAN Management Protocol for Cisco Broadband Access Center (BAC).

This chapter includes the following sections:

• CWMP Overview, page 4-1

• Cisco BAC Device Object Model, page 4-2

• Discovering CPE Parameters, page 4-4

• Multi-Instance Object Support, page 4-5

• Instruction Generation and Processing, page 4-14

• Device Deployment in Cisco BAC, page 4-16

• Initial Provisioning Flows, page 4-18

• Assigning Devices to Provisioning Groups, page 4-20

• Device Diagnostics, page 4-21

• Configuring SNMP Trap for CPEs, page 4-21

CWMP Overview

Cisco BAC communicates with CPE through the CPE WAN Management Protocol (CWMP) according to parameters described in the TR196, TR-069, and other related data model specifications. CWMP encompasses secure management of CPE, including:

• Autoconfiguration and dynamic service provisioning

• Firmware management

• Device diagnostics

• Performance and status monitoring

Cisco BAC supports devices based on the TR-069, TR-098, TR-104, TR-106, TR-181, and TR-196 standards. This support includes Ethernet and ADSL gateway devices, wireless gateways, VoIP ATAs, and other devices compliant with CWMP. This release also provides for runtime-extensible data models to support any upcoming data-model standards or any vendor-specific data models.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

4-1

Cisco BAC Device Object Model

The Cisco BAC device object model is crucial in controlling the configuration and firmware rules that are generated as instructions for the DPE to manage devices. This process occurs at the RDU, and is controlled through named attributes and relationships.

The main objects in the device object model are:

• IPDevice—Represents a network entity that requires provisioning.

• Owner ID—Represents an external identifier for a subscriber.

• Device Type—Represents the type of the device.

• ProvGroup—Represents a logical grouping of devices serviced by a specific set of DPEs.

• Class of Service—Represents the configuration profile to be assigned to a device.

• File—Serves as a container for files used in provisioning that include templates and firmware

images.

• Group—Is a customer-specific mechanism for grouping devices.

Common among the various objects in the Cisco BAC device data model are:

• Name. For example, Gold Class of Service

• Attributes. For example, Device ID and a fully qualified domain name (FQDN)

Chapter 4 CPE Management Overview

• Relationships. For example, the relationship of a device to a Class of Service

• Properties. For example, a property which specifies that a device must be in a provisioning group.

See Figure 4-1 for a description of the interaction between the various objects in the device data model.

Figure 4-1 Device Object Model

Prov Group Class of Service

1..1

0..* 0..2

File

0..*

1..1

0..*

IPDevice

1..*

0..* 0..n

Group

0..*

0..n

0..*

1..1

0..1

Device Type Owner ID

Group Type

1..1

158269

4-2

In the Cisco BAC device object model, the IPDevice is related to the Class of Service, the Provisioning Group, and the Device Type. The Class of Service is then related to the Configuration Template and the Firmware Rules Template. Files can be related to one another, such as the firmware rules template being related to the firmware image.

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 4 CPE Management Overview

Table 4- 1 describes the attributes and relationships unique to each object in the data model.

Table 4-1 Device Object Relationships

Object Related to ...

IP Device

Cisco BAC Device Object Model

• Could be preregistered or unregistered (See Device

Deployment in Cisco BAC, page 4-16).

• Attributes include Device ID (OUI-Serial) and FQDN

Owner ID

• Is associated with devices and, therefore, cannot exist

without a device related to it.

• Enables grouping; for example, you can group all devices

belonging to Joe.

Device Type

• Stores defaults common to all devices of a technology,

specifically CWMP.

• Enables grouping; for example, you can group all CWMP

devices.

File

• Stores files used in provisioning; for example,

configuration template and firmware rules template

Class of Service

• Attributes include Type, Name, and Properties. (For

details, see Class of Service, page 4-3.)

• Owner ID

• Provisioning Group

• Class of Service

• Device Type

IP Device

Class of Service

• IP Device

• File

• Configuration Template

(optional)

• Firmware Rules Template

(optional)

OL-27172-01

Class of Service

Class of Service is an RDU abstraction that represents the configuration to be handed to the device in the form of templates. It enables you to group devices into configuration sets, which are service levels or different packages that are to be provided to the CPE.

The different Classes of Service are:

• Registered—Specified by the user when the device is registered. This Class of Service is explicitly

added to the device record using the application programming interface (API).

• Selected—Selected by the RDU for a device that, for one reason or another, cannot retain its

registered Class of Service.

• Related—Related to the device by being registered, selected, or both.

If the selected Class of Service for a device is changed, the Instruction Generation Service regenerates instructions for the device configuration.

Cisco Broadband Access Center 3.8 Administrator Guide

4-3

Discovering CPE Parameters

If the registered Class of Service for a device is changed, it regenerates instructions for the generated device configuration even if it is not the selected Class of Service, since it could impose a policy that would change the selected Class of Service.

Other concepts related to the device data model are:

• Property Hierarchy, page 4-4

• Custom Properties, page 4-4

Property Hierarchy

While processing configuration templates for substitutable parameters, Cisco BAC searches objects for this property using a certain order called Property Hierarchy.

Cisco BAC properties allow you to access and store data in Cisco BAC using the API. Preprovisioned, discovered, and status data can be retrieved through the properties of corresponding objects, using the API. Properties also enable you to configure Cisco BAC at the appropriate level of granularity (from system level to device groups and to individual devices).

The Cisco BAC property hierarchy gives you the flexibility to define system-wide or service class defaults that can be overridden by individual devices.

Cisco BAC allows you to store any number of properties on objects in its data model. You can reference these properties in configuration templates or firmware rules. You can use properties in this property hierarchy:

1. Device

Chapter 4 CPE Management Overview

2. Group (priority is set through the Group Type, see Managing Group Types, page 16-18)

3. Provisioning Group

4. Class of Service

5. Device Type

6. System Defaults

Custom Properties

Custom properties allow for the definition of new properties, which can then be stored on any object via the API.

Custom properties are variable names defined in the RDU, and must not contain any spaces. The template parser works from bottom up when locating properties in the hierarchy and converts the template option syntax. For detailed information, see Custom Properties, page 5-15.

Discovering CPE Parameters

Cisco BAC is enabled to read CPE parameters using Remote Procedure Calls (RPCs) as defined in CWMP. This is made possible through the Data Synchronization Instruction. This instruction discovers data from the CPE device, reports it to the RDU, and keeps the RDU up-to-date when CPE device data changes.

4-4

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 4 CPE Management Overview

This instruction can be used to keep the RDU up-to-date on such key parameters as the software version and the model name. These parameters may, in turn, be used to generate other instructions, such as configuration instructions specific to a given device type.

Table 4- 2 lists the default parameters that Cisco BAC discovers.

Table 4-2 Default Discovered Parameters

Parameter Description

Inform.DeviceId.Manufacturer Identifies the manufacturer of the CPE.

Inform.DeviceId.ManufacturerOUI Identifies the unique identifier of the CPE manufacturer.

Inform.DeviceId.ProductClass Identifies the product or class of product over which the

InternetGatewayDevice.DeviceInfo. HardwareVersion

InternetGatewayDevice.DeviceInfo. SoftwareVersion

InternetGatewayDevice.DeviceInfo. ModelName

InternetGatewayDevice. ManagementServer.ParameterKey

Multi-Instance Object Support

manufacturer’s SerialNumber parameter is unique.

Identifies the hardware version of the CPE.

Identifies the software version currently installed on the CPE.

Identifies the model name of the CPE.

Specifies the value of the Parame t e rKey from the most recent SetParameterValues, AddObject, or DeleteObject call from the server.

These parameters can be updated using the API (using the /server/acs/discover/parameters property) or via the administrator user interface (see Discovering Data from Devices, page 12-11).

Note Even if the device has a different root object, such as Device, instead of InternetGatewayDevice, the

parameters are still discovered.

Multi-Instance Object Support

In this release, the multi-instance object support introduces the ability to discover the multi-instance object parameters from the device without specifying the actual instance number. Multi-instance object support is available as an usability improvement in the following BAC modules to aid deployment:

• Configuration Template

• Firmware Rules Template

• Parameter Discovery

• Display Live Data Operation

This feature will be functional only when the RDU and all the DPEs are upgraded to Cisco BAC 3.8. To configure the configuration template and the firmware template with multi-instance objects the value of the newly introduced templateVersion attribute value should be 3.0.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

4-5

Multi-Instance Object Support

Configuration Template

Earlier to this release of BAC, the scope of configuration template represented only the possible set parameter values and set parameter attributes that could be performed. There was no mechanism to discover object names.

In this release, the template scope is extended to include the following:

• The ability to discover object names

• The ability to discover parameter values

• The ability to delete object instances

• The ability to add object instances

A new attribute sync-method is introduced in the configuration template. The sync-method instructs the configuration sync process to interact with the device to discover the object instances. For the discovered object instances the ACS has total control to configure the parameters available in the object’s sub-tree. The following are the available sync-methods.

Sync-method Description

discovered If this condition is specified, BAC discovers the object instances based on the

replace-all If this condition is specified, BAC first discovers the parameter value for the

Chapter 4 CPE Management Overview

instance attribute value specified for the object instance.

specified parameter name from all the object instances. For the discovered object instances the following operations are possible:

• If a matching object instance is found with the specified parameter value, it

updates the object instance with the new parameter value.

• If no matching instance is found, BAC creates an object instance with the new

parameter value.

• If an object instance is found with the different parameter value, that object

instance is deleted.

replace-augment This operates same as replace-all, except that BAC retains the instances that does

not match the parameters configured.

delete-all If this condition is specified, BAC simply deletes all the available instances at that

level.

delete If this condition is specified, BAC deletes the instance that match the value specified

in the instance attribute.

Any one of the following instance attribute must be mandatorily used with discovered and delete sync-method:

• all() - This option indicates BAC to discover all the instances

• last() - This option indicates BAC to discover the last instance

• compare(parameterName operation matchValue) - This option indicates BAC to discover the object

instances in which the parameter and the value are in accordance with the operation.

Note Valid compare operators are: equals, equalsIgnoreCase, notEquals, lessThan, lessThanEquals,

greaterThanEquals, greaterThan.

4-6

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 4 CPE Management Overview

• Index - This option can be used for direct indexing and accepts a valid positive integer. This is the

index into the returned instance names. For example, index value 1 returns the first instance.

In configuration template, the expression parameters in pre-requisites can also be configured with multi-instance object parameters, with any of the discovered options. For more information on prerequisites, see Prerequisites, page 5-9.

Example 4-1 Multi-Instance Object Using replace-all in Configuration Template

The following example illustrates usage of multi-instance object using replace-all in configuration template:

<ParameterDictionary>tr196-cwmp-dictionary-v2.0.xml</ParameterDictionary>

</ParameterDictionaries> <ObjectInstance name="Device">

sync-method="replace-all" primary-keys="PLMNID,LAC,RNCID">

defaultValue=123452)</Value>

Multi-Instance Object Support

<ObjectInstance name="IntraFreqCell"

<Name>PLMNID</Name>

<Value>VAR(name=FC-PLMN-ID,

</Parameter> <Parameter>

<Name>RNCID</Name>

</ObjectInstance> <ObjectInstance name="">

<Name>PLMNID</Name>

<Name>RNCID</Name>

</ObjectInstance>

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

4-7

Multi-Instance Object Support

</Configuration>

The behavior of BAC to apply the above template configuration during configuration sync is explained

below:

1. BAC retrieves GetParameterNames RPC data for the object Device.Services.FAPService. with next

2. Since all() option is configured, it uses all of the returned instances for further processing.

3. BAC searches the PLMNID, LAC and RNCID by issuing GetParameterValues RPC for the

4. For all the matching instances that have a value of PLMNID equals 123452, LAC equals 65532 and

5. For all the matching instances that have a value of PLMNID equals 123452, LAC equals 65533 and

Chapter 4 CPE Management Overview

</ObjectInstance>

</ObjectInstance> </ObjectInstance> </ObjectInstance> </ObjectInstance>

</ObjectInstance>

level option set to true.

parameter Device.Services.FAPService.{all()}.CellConfig.UMTS.RAN.NeighborList.IntraFreqCell.{i}.PLM NID, Device.Services.FAPService.{all()}.CellConfig.UMTS.RAN.NeighborList.IntraFreqCell.{i}.LAC and Device.Services.FAPService.{all()}.CellConfig.UMTS.RAN.NeighborList.IntraFreqCell.{i}.RNC ID for all the instances.

RNCID equals 18, SetParameterValues is performed with the configured RAC value 10.

RNCID equals 21, SetParameterValues is performed with the configured RAC value 11.

6. If a matching instance is not found for the configured PLMNID, LAC, RNCID values, a new

instance is created using AddObject RPC and the configured values of PLMNID, LAC, RNCID and RAC are applied on the new instance.

7. If there are instances available on the device that does not match the PLMNID, LAC and RNCID,

they are deleted using DeleteObject Message.

Example 4-2 Multi-Instance Object Using delete-all in Configuration Template

The following example illustrates usage of multi-instance object using delete-all in configuration template:

<ParameterDictionary>tr196-cwmp-dictionary.xml</ParameterDictionary>

</ParameterDictionaries> <ObjectInstance name="Device"> <ObjectInstance name="Services">

</ObjectInstance>

</Configuration>

4-8

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 4 CPE Management Overview

The behavior of BAC to push the above template configuration during configuration sync is explained below:

1. BAC discovers the instances in the object Device.Services.FAPService. by issuing

GetParameterNames RPC with next level set to true.

2. Since last() method is used, it gets the last instance and discovers the instances in the next level by

issuing GetParameterNames RPC for the parameter Device.Services.FAPService.{last()}.REM.UMTS.GSM.Cell.{i}. with next level set to true.

3. BAC performs DeleteObject one by one on all the instances returned.

Example 4-3 Multi-Instance Object Using delete in Pre-requisites of Configuration Template

The following example illustrates usage of multi-instance object using delete in pre-requisites of configuration template:

<ParameterDictionary>tr196-cwmp-dictionary.xml</ParameterDictionary> </ParameterDictionaries> <Prerequisites>

</MaintenanceWindow>

</Expression> </Prerequisites> <ObjectInstance name="Device"> <ObjectInstance name="Services">

</ObjectInstance> </ObjectInstance>

</Configuration>

Multi-Instance Object Support

<ParameterName>Device.Services.FAPService.{i}.REM.UMTS.GSM.Cell.{i}.BSIC </ParameterName> <InstanceConfiguration>

<Path>Device.Services.FAPService.{i}.REM.UMTS.GSM.Cell.</Path>

<Value>compare(LAC lessThanEquals 65534)</Value> </Instance> <Instance>

<Path>Device.Services.FAPService.</Path>

</InstanceConfiguration> <Value>18</Value> <Operator>matchAllIgnoreCase</Operator>

</ObjectInstance>

OL-27172-01

The behavior of BAC to apply the above template configuration during configuration sync is explained below:

1. During configuration sync execution, BAC validates the time to ensure that the configuration sync

falls in the maintenance window

Cisco Broadband Access Center 3.8 Administrator Guide

4-9

Multi-Instance Object Support

2. Next, BAC validates the expression. Since the expression parameters are configured with

3. After the expression is evaluated to true, BAC discovers the instance for

4. To discover the multi-instance object at next level, it issues GetParameterNames RPC for

5. Finally, BAC issues DeleteObject Message for the instance in the second index in the returned array.

Example 4-4 Invalid Example-Adding a Template Without Instance Attribute

The following example illustrates adding a template without the instance attribute.

<tc:Template xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tc="urn:com:cisco:bac:common-template" xmlns="urn:com:cisco:bac:cwmp-template" xsi:schemaLocation="urn:com:cisco:bac:common-template CommonTemplateConstructs.xsd">

<ParameterDictionaries> <ParameterDictionary>tr196-parameter-dictionary.xml</ParameterDictionary> </ParameterDictionaries>

<Parameter> <Name>Enable</Name> <Value>true</Value> </Parameter> <Parameter> <Name>IMSI</Name> <Value>310410268739757</Value> </Parameter> </ObjectInstance> </ObjectInstance> </ObjectInstance> </ObjectInstance> </ObjectInstance>

</tc:Template>

Chapter 4 CPE Management Overview

multi-instance object parameters, BAC first discovers and identify the instances to evaluate the expression.

Device.Services.FAPService. by using GetParameterNames RPC with next level set to true.

Device.Services.FAPService.{last()}.REM.UMTS.GSM.Cell.

</ObjectInstance>

</Configuration>

When this template is added through API or admin UI, the following validation error is displayed:

Error: Template file validation has failed with the following error. [Missing instance attribute for the sync-method 'discovered']

Firmware Rules Template

Earlier to this release, the expression support in the firmware rules was not flexible enough to handle multi-instance objects in the parameter names. This enhancement is extended to firmware rules template where BAC discovers the multi-instance parameters to evaluate the expression.

Cisco Broadband Access Center 3.8 Administrator Guide

4-10

OL-27172-01

Chapter 4 CPE Management Overview

You can specify multi-instance parameter name in the expression, and the discover mechanism of these objects can be configured using the newly introduce template element InstanceConfiguration.

Example 4-5 Multi-Instance Object in Expression

The following example illustrates usage of multi-instance object in expression:

<ParameterName>Device.Services.FAPService.{i}.REM.GSM.Cell.{i}.LAC

</ParameterName>

</InstanceConfiguration> <Value>4660</Value> <Operator>match</Operator>

</Expression>

Multi-Instance Object Support

<Path>Device.Services.FAPService</ Path> <Value>last()</Value >

</Instance> <Instance>

<Path>Device.Services.FAPService.{i}.REM.GSM.Cell</ Path> <Value>compare(PLMNID equals 123456)</Value >

</Instance> <MatchCondition>OR</MatchCondition>

In the above expression the multi-instance object parameter name Device.Services.FAPService.{i}.REM.GSM.Cell.{i}.LAC is used. The InstanceConfiguration discovers the multi-instance object instances Device.Services.FAPService.{i} and Device.Services.FAPService.{i}.REM.GSM.Cell.{i}. The Value tag supports all the available instance discover methods like all(), last(), compare(parameterName operation matchValue) and index. The new tag MatchCondition is available in the instance configuration, which is used to evaluate the multiple expressions only in case there are multiple instances discovered.

Example 4-6 Multi-Instance Object in Firmware Rule Template

The following example illustrates usage of multi-instance object in firmware rule template:

<tc:Template xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tc="urn:com:cisco:bac:common-template" xmlns="urn:com:cisco:bac:firmware-template" xsi:schemaLocation="urn:com:cisco:bac:common-template CommonTemplateConstructs.xsd">

<FirmwareTemplate templateVersion="3.0"> <ParameterDictionaries> <ParameterDictionary>tr196-cwmp-dictionary-v2.0.xml</ParameterDictionary> </ParameterDictionaries>

</MaintenanceWindow>

OL-27172-01

<ParameterName>Device.Services.FAPService.{i}.REM.UMTS.GSM.Cell.{i}.BSIC</ParameterName>

<Path>Device.Services.FAPService.{i}.REM.UMTS.GSM.Cell.</Path>

<Value>compare(LAC lessThanEquals 65534)</Value>

Cisco Broadband Access Center 3.8 Administrator Guide

4-11

Multi-Instance Object Support

Chapter 4 CPE Management Overview

</Instance> <Instance>

<Path>Device.Services.FAPService.</Path>

</InstanceConfiguration> <Value>18</Value>

<Operator>matchAllIgnoreCase</Operator> </Expression> <Expression>

<ParameterName>Device.Services.FAPService.{i}.REM.UMTS.GSM.Cell.{i}.PLMNID</ParameterName>

</Prerequisites>

<ParameterName>Device.Services.FAPService.{i}.REM.UMTS.GSM.Cell.{i}.BSIC</ParameterName>

<Path>Device.Services.FAPService.</Path>

<Path>Device.Services.FAPService.{i}.REM.UMTS.GSM.Cell.</Path>

</InstanceConfiguration> <Value>123451</Value> <Value>123452</Value> <Operator>matchIgnoreCase</Operator>

</Expression>

<InformParameterName>Inform.EventCode</InformParameterName> <Value>1 BOOT</Value> <Value>2 PERIODIC</Value> <Operator>match</Operator>

</Expression>

<Path>Device.Services.FAPService.{i}.REM.UMTS.GSM.Cell.</Path>

<Path>Device.Services.FAPService.</Path>

<Value>compare(DeviceType equalsIgnoreCase fap)</Value> </Instance> <MatchCondition>OR</MatchCondition>

</InstanceConfiguration> <Value>18</Value> <Operator>matchAllIgnoreCase</Operator>

</Expression>

4-12

<FileName>sample-firmware-image.bin</FileName> <DeliveryTransport>service http 1</DeliveryTransport>

</InternalFirmwareFile> </FirmwareRule> </FirmwareTemplate> </tc:Template>

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 4 CPE Management Overview

Parameter Discovery

Multi-instance object parameters can now be specified in the data discovery. This support is extended for preregistered and unregistered devices.

Preregistered Devices

For preregistered devices, the multi-instance object parameters can be configured in the parameter

IPDeviceKeys.CWMP_CUSTOM_DISCOVER_PARAMETERS as in the example below:

/IPDevice/custom/discover/parameters= Device.Services.FAPService.{i}.REM.GSM.Cell.{i}.LAC, Device.Services.FAPService.{i}.REM.GSM.Cell.1.PLMNID

Unregistered Devices

For unregistered devices, the multi-instance object parameters can be configured in the parameter

ServerDefaultsKeys.CWMP_UNKNOWN_CPE_PARAMETERS as in the example below:

/server/acs/unknown/parametersToRetrieve= Device.Services.FAPService.{i}.REM.GSM.Cell.{i}.LAC, Device.Services.FAPService.{i}.REM.GSM.Cell.1.PLMNID

Multi-Instance Object Support

Display Live Data Operation

The device operation enables you to view live device parameter values. The parameters retrieved from the device are selected from a Parameter List file, which is an XML file that details all the parameters.

If the multi-instance object parameters are configured in the Parameter List XML file, the device operation retrieves the parameter values from all the available instances in the device.

The following example illustrates the usage of multi-instance object support to retrieve live device data.

<ParameterDictionary>tr196-cwmp-dictionary-v2.0.xml</ParameterDictionary> </ParameterDictionaries> <Parameter>

<Name> Device.Services.FAPService.{i}.REM.GSM.Cell.{i}.LAC</Name> </Parameter>

<Name> Device.Services.FAPService.{i}.REM.GSM.Cell.1.PLMNID </Name> </Parameter>

<Name>Device.Services.FAPService.{i}.REM.UMTS.GSM.CellNumberOfEntries</Name> </Parameter> </ParameterList>

Instance Sorting

OL-27172-01

In all the operations, when selecting the instances based on the instance configuration, you sort the list of instances returned in GetParameterNames RPC call. The discovered object instances can be sorted when the property

ProvGroupKeys.ENABLE_INSTANCE_SORTING (/provGroup/enable/instanceSorting) is

enabled.

This property can be configured at the Provisioning Group level in the object hierarchy. For details, see

Provisioning Group Configuration Workflow, page 3-8.

Cisco Broadband Access Center 3.8 Administrator Guide

4-13

Instruction Generation and Processing

Instruction generation is the process of generating specific instruction sets for CWMP devices. By using technology extensions, through which device technologies are incorporated into Cisco BAC, device details are combined with provisioning rules to produce instruction sets appropriate to the CPE. These instructions are then forwarded to the DPEs in the device’s provisioning group and cached there.

The scriptable extensions are also supported in Cisco BAC. The extension points are defined in DPE for running the java based extension scripts. These scripts are executed in DPE, whenever the device establishes connection with the DPE. The extension scripts are added in the RDU database and forwarded to the DPE cache. For more information on scriptable extension service, see Scripting

Framework, page 18-1.

When a device is activated in a Cisco BAC deployment, it initiates contact with the Cisco BAC server. After contact is established, the device’s preconfigured policy, based on configuration templates or firmware rules templates associated with the device, determine the management actions undertaken by the DPE.

This preconfigured policy determines the device’s level of service, also known as Class of Service. Device configurations can include customer-required provisioning information, such as authentication information, periodic inform rate, and Class of Service. This authoritative provisioning information for the device is forwarded to DPEs from the RDU as device configuration instructions.

Instructions are logical operations which the DPE autoconfiguration server (ACS) performs for a specific device. The instructions may map directly into a CWMP remote procedure call (RPC), for example, GetParameterValues; or, they may combine additional logic with multiple CWMP RPCs, such as firmware rules.

IGS could be controlled using the new API property, ApiCommandKeys.IGS_ENABLE. This property determines whether IGS should be triggered or not. The API command uses this property to control the regeneration of device configuration being affected by other API commands.

Chapter 4 CPE Management Overview

When this property is set to False in the map of associated properties of an API command, the command skips the regeneration of the configuration process and it returns immediately with a warning message. The API commands affected by this property are:

• replaceFile

• changeClassOfServiceProperties

• changeProvGroupProperties

• changeNodeProperties

• changeDefaults

For the list of other API commands see Non-concurrent Commands, page 19-2.

The RDU requests that instructions be processed, by passing “InstructionRecords” to the DPE. The DPE server then converts these “InstructionRecords” to “Instructions”, and returns the results to the RDU as “InstructionResponseRecords”.

Cisco BAC generates instructions through:

• The Instruction Generation Extension—Generates “InstructionRecords” for a single device.

• The Instruction Generation Service—Generates “InstructionRecords” for more than one device.

You can access statistics from the Instruction Generation Service from the administrator user interface at Servers > RDU > View Regional Distribution Unit Details.

Among the various instructions that the RDU generates are:

4-14

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 4 CPE Management Overview

• Data Synchronization Instruction (DataSyncRecord)—Keeps the RDU up-to-date on various CPE

parameters, such as the software version and the model name. These parameters may, in turn, be used in generating other instructions, such as configuration instructions that are specific to a given device type.

Some parameters are checked on every connection, while others are checked only when a change in the firmware version occurs. For details, see Discovering Data from Devices, page 12-11.

• Routable IP Address Instruction (RoutableIPAddressRecord)—Discovers if a particular device is

reachable, enabling the DPE to create a TCP connection with a device in order to service a connection request. The instruction retrieves the WAN IP address for the device, PPP or DHCP, and compares it with the source IP address. If the IP addresses are different, the instruction updates the RDU.

• Firmware Rules Instruction (FirmwareRulesRecord)—Determines the firmware image to be

downloaded to a device. The firmware image files are associated to groups of devices by a firmware rules template.

Cisco BAC uses the rules in the associated template to evaluate the firmware to be downloaded to the CPE. This instruction takes effect only if the device has been associated with a firmware rules template.

• Configuration Synchronization Instruction (ConfigSyncRecord)—Triggers a synchronization of the

CPE configuration that is stored in the DPE cache. This instruction comes into effect only if the device has been associated with a configuration template. The process of configuration synchronization is explained in the subsequent section.

When the Signed Configuration feature is enabled, the RDU parses the ToBeSigned tag specified in the configuration template and sets the corresponding value on the CWMP parameter object.

By default, the ToBeSigned flag on the CWMP parameter object is set to False. For more information on Signed Configuration, see Signed Configuration for Devices, page 13-20.

Instruction Generation and Processing

Device Configuration Synchronization

During the process of CPE configuration synchronization, a device’s configuration is automatically synchronized based on the configuration template associated with the device’s Class of Service object. The process of synchronizing the CPE configuration according to the ConfigSync instruction stored in the DPE for this device is called Configuration Synchronization.

As part of this process, the DPE configures all parameters values and attributes found in the configuration template associated with a device through its Class of Service, so that:

• Notifications reflect those configured in the configuration template. For more information on

Notifications, see Notification, page 5-8.

• Access control for all parameters reflects that configured in the configuration template. For more

information on access control, see Access Control, page 5-9.

CPE configuration is associated with a unique configuration key. This configuration key is saved in the DPE database, and is used as the Par a meter Key parameter in RPCs that are forwarded to the CPE.

Every time the CPE establishes a connection with the DPE, the device reports the value for the Parameter Key—in the form of a configuration revision number—by using the Inform message that the device forwards to the DPE. The DPE compares this value with the one in its cache for the particular device. A mismatch of the values, triggers the DPE and the device synchronization process.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

4-15

Device Deployment in Cisco BAC

During the process of configuration synchronization:

1. The DPE receives a Paramete r Key from the device. If the value of this Para met e r Key matches the

one stored in the DPE, no synchronization is initiated. If the Para m e terKey values differs, the synchronization process continues.

2. If access control is set in its configuration, the DPE sets the AccessList parameter to ACS-only. The

access control feature is, by default, enabled. For more information on access control, see Access

Control, page 5-9.

3. If you enable the notification feature, the DPE sets notification attributes as specified in the device

configuration. Notifications are, by default, enabled. For more information on notifications, see

Notification, page 5-8.

4. After the DPE configures the parameter values on the device according to the template, it sets a new

configuration revision number in the Par a mete r Key argument. This revision number is used to determine if the device configuration is synchronized the next time the device and the DPE establish a connection.

If the device connection with the DPE times out during the synchronization process, the CPE attempts to reconnect to the DPE.

In this scenario, the value of the Param ete rKey in the Inform message remains the same, because only a successful synchronization process changes the Par a meter Key value. When the CPE reconnects to the DPE, the DPE initiates another round of synchronization with the original Parameter Key value.

5. The synchronization process ends with the DPE forwarding the new value for the Parame t e rKey

attribute in its last update to the CPE.

Chapter 4 CPE Management Overview

In some situations, you must update the device even if the Parameter Key on the DPE matches the one on the device.

To force a configuration synchronization:

Step 1 From the Devices page, locate the device whose configuration you want to synchronize.

Step 2 Click the Operations icon ( ) corresponding to the device.

The Device Operations page appears.

Step 3 From the drop-down list under Perform Device Operation, select Force Configuration Synchronization.

Step 4 Click Submit.

The device configuration is synchronized with the DPE.

Device Deployment in Cisco BAC

A Cisco BAC deployment is divided into provisioning groups, with each provisioning group responsible only for a subset of the devices. All services provided by the provisioning group are implemented to provide fault tolerance.

4-16

Note A key principle of device management is that the RDU does not directly communicate with

devices. All device interactions are delegated to DPEs in the provisioning group to which the device belongs.

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 4 CPE Management Overview

Cisco BAC provides two device deployment options, which can also be used in combination:

• Preregistered—The device record is added to the RDU before the device makes initial contact with

the DPE, also known as the ACS.

• Unregistered—The device makes contact with the DPE, before the device record is added to the

RDU.

Preregistered Devices

In this scenario, device data is preprovisioned into Cisco BAC, and the device is associated with a specific Class of Service. The Class of Service can correspond to a service that the subscriber registered for or a default configuration.

A preregistered device is preconfigured with certain parameters specific to the service provider. These parameters are typically “burnt-in” as factory defaults.

Note If you reset the device to factory defaults, the settings on the device revert to the preburnt configuration,

and the device may go through the reconfiguration process.

Device Deployment in Cisco BAC

Device data is preregistered in Cisco BAC. This is typically done through the API; alternatively, it can be done using the administrator user interface.

Preconfiguration involves three important issues:

• The device must be able to establish network connectivity. For DSL devices, this typically involves

using auto-detection of ATM PVC and using PPP for authentication. The IP address is obtained using PPP or using DHCP. Other devices typically use an existing internet connection and local DHCP for address assignment.

• CPE must contact the configuration servers of the appropriate service provider; in other words, the

CPE must know the ACS URL. The ACS URL can be preburnt into the device (assigned) or discovered using DHCP from the WAN side.

• The service provider must be able to associate the CPE with a specific subscriber. This process is

typically accomplished by the Operations Support Systems (OSS) application responsible for subscriber registration. Cisco BAC is updated with appropriate data to provision device configuration.

Unregistered Devices

In this scenario, no device data is prepopulated into Cisco BAC. Device data is added to Cisco BAC only when the device first contacts a Cisco BAC server.

Cisco BAC allows unregistered devices (with no preconfigured parameters) to appear on a network and gain default access. However, the lack of support for preregistering device data into Cisco BAC restricts authentication options for unregistered devices, to using mechanisms based on certificates as opposed to shared secrets.

The lack of preregistered data also means that Cisco BAC has to dynamically classify the devices and determine the default configuration of a device.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

4-17

Initial Provisioning Flows

System Operator

Populate Provisioning

Rules

RDU Provisioning Group CPE

Add CPE (optional)

Deliver Instruction Set

CPE Makes Protocol X response

Yes, Send Protocol X response

Do I have Instructions?

158331

Generate Instruction

Set

Store Discovered

Data

Note With no preregistered device data available, the chances of a Denial of Service attack increase, as

unknown devices are not authenticated.

Initial Provisioning Flows

This section describes the configuration workflow for a device, which differs based on whether a device is preregistered or unregistered.

Figure 4-2 shows a common initial configuration flow.

Figure 4-2 Initial CPE Configuration Workflow

Chapter 4 CPE Management Overview

For Preregistered Devices

4-18

a. From the Cisco BAC API, the RDU is populated with specifically defined configurations and rules

for various types of devices. The device is preconfigured and associated with a Class of Service.

b. The preregistered device finds its provisioning group by contacting the Cisco BAC server at a

preconfigured URL, and initiates autoprovisioning with provisioning group servers (DPEs).

c. The RDU generates instructions appropriate for the device. The resulting device instructions direct

DPE responses to various CPE protocol events, such as a TR-069 Inform and an HTTP file request.

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 4 CPE Management Overview

d. The device instruction set is forwarded to the DPE and cached there. Now, the DPE is programmed

to handle subsequent CPE protocol interactions for this device autonomously from the RDU. After the device is added to the network and a configuration is generated for the device, the device boots to allow the DPE to begin its interactions with the preregistered device.

e. During interactions with the device, additional information can be discovered and forwarded to the

RDU. In this case, the RDU may decide to generate new instructions and forward them to all DPEs.

For Unregistered Devices

a. From the Cisco BAC API, the RDU is populated with specifically defined configurations and rules

for various device types.

b. During bootup, when the DPE receives a device request, it performs a local search for instructions

cached for the specific CPE. Because the CPE has never previously contacted the DPE and because device data was not preregistered into Cisco BAC, no instructions are found.

The DPE then packs all relevant CPE information into an “instruction set” generation request, and forwards the request to the RDU. At the same time, the device request is rejected, forcing the device to retry. Also, the device receives the configured SOAP request/response extensions from DPE cache and the extensions are executed for the device. Unknown device extensions are configured in CWMP defaults and are sent to DPE cache. For more information on configuring extensions for unknown devices, see Configuring Extensions for Unknown Devices, page 18-4.

c. The RDU generates instructions appropriate for the CPE and distributes it to all DPEs within the

device’s provisioning group. The resulting CPE instructions direct DPE responses to various CPE protocol events, such as a TR-069 Inform, and an HTTP file request.

Initial Provisioning Flows

d. The CPE is now registered and the details are stored in the RDU. The RDU captures the CPE

registration time. The property to retrieve the registered time is /IPDevice/registeredTime. This property value can be obtained through the API IPDevice.getDetails() call.

e. The device instruction set is delivered to the DPE and cached there. Now, the DPE is programmed

to handle all subsequent CPE protocol interactions for this device autonomously from the RDU.

The following parameters are discovered by Cisco BAC for unknown devices:

• Whether the device IP address is routable or NAT’ed.

• Inform.DeviceId.Manufacturer.

• Inform.DeviceId.ManufacturerOUI.

• Inform.DeviceId.ProductClass.

• InternetGatewayDevice.DeviceInfo.HardwareVersion.

• InternetGatewayDevice.DeviceInfo.SoftwareVersion.

• InternetGatewayDevice.DeviceInfo.ModelName.

• InternetGatewayDevice.ManagementServer.ParameterKey.

Note You can change the default list of discovered parameters. See Discovering Data from

Devices, page 12-11.

f. The device then reconnects, and receives the configuration instructions generated for it from the

RDU and cached at the DPE.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

4-19

Assigning Devices to Provisioning Groups

Devices can be assigned to a provisioning group in three ways: explicitly, automatically, or using a combination of both.

Explicit Assignment

You can explicitly assign a device to a provisioning group. After devices appear in the default provisioning group, the provisioning system may, using the API, assign the device to a new provisioning group. On next contact with the device, Cisco BAC redirects the device.

To set the device to contact the assigned provisioning group, change the URL of the Cisco BAC server to the URL of the provisioning group URL. The Cisco BAC server URL is stored, and from then on, the device contacts Cisco BAC at the new address.

To move the device from one provisioning group to another, change the home provisioning group of the device using the API or the administrator user interface. Each provisioning group has a URL associated with it. To facilitate the move, on next contact, the ACS URL on the device is changed to the new provisioning group URL.

Chapter 4 CPE Management Overview

Automatic Membership

If a device has not been explicitly assigned to a provisioning group, the device stays in the provisioning group in which it is brought up. This allows a network-directed assignment of CPE to the provisioning groups. You can use the automatic membership feature for roaming devices, enabling the local provisioning group to service these devices when they are moved.

When a device appears in a new provisioning group, it is automatically assigned to the new provisioning group, and the device data is purged from the old provisioning group. This process involves communicating with the RDU, which, in turn, updates the DPEs in the old and new provisioning groups. This is an expensive process; therefore, take care to prevent a large number of device migrations.

Automatic assignment of a device to a provisioning group works only if the DPEs are configured to allow unknown (unregistered) devices that do not show up in any provisioning group.

If the devices do show up in another provisioning group and the provisioning group is configured to allow access for unknown devices, Cisco BAC automatically assigns the device to the provisioning group.

For details on how to configure access for unknown devices, see the Cisco Broadband Access Center 3.8

DPE CLI Reference.

Combined Approach

You can explicitly assign devices and allow automatic membership of devices to a provisioning group. For example, a generic unregistered device that appears on the network in a provisioning group is automatically assigned to it. Subsequently, the OSS explicitly assigns the device to another provisioning group by using the API.

4-20

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 4 CPE Management Overview

Device Diagnostics

CWMP supports device troubleshooting and diagnostics features that you use to focus on a single device and collect diagnostics information for further analysis. This feature enables you to query devices for any data, including:

• Configuration

• Live statistics

• Fault indications

• Log file

• Diagnostics results

Device diagnostics is made possible in Cisco BAC through a set of operations that can be run on the device. These include:

• Reboot—Reboots the device. This reboot is primarily intended for diagnostic purposes.

• Request Connection—Initiates a connection request with Cisco BAC.

• Factory Reset—Resets a preregistered device settings to its original factory settings, to before a

subscriber-specific configuration was burnt in.

• Display Live Data—Views device parameters directly from a device. You can define the parameters

you want to appear.

• Ping Diagnostic—Enables you to perform an IP ping diagnostics test from the device to any host.

Device Diagnostics

• Force Firmware Upgrade—Forces a CPE to update its firmware.

• Force Configuration Synchronization—Enables you to force an individual CPE to synchronize its

configuration.

For details on performing these device operations, see Performing Operations on Devices, page 16-14.

Cisco BAC also provides the following features to help troubleshooting:

• Device History—Provides a detailed history of significant events that occur in a device provisioning

lifecycle. See Device History, page 8-1.

• Device Faults—Detects devices with recurring faults, which can cause bottlenecks and affect

network performance. See Device Faults, page 8-6.

• Device Troubleshooting—Provides detailed records of device interactions with Cisco BAC servers

for a set of devices that are designated for such troubleshooting. See Device Troubleshooting,

page 8-9.

• Performance Statistics—Provides detailed performance statistics that are related to system

performance across major components. It also provides an analysis of the statistical data to aid troubleshooting. See Monitoring Performance Statistics, page 11-14.

Configuring SNMP Trap for CPEs

The fault management module of Cisco BAC facilitates CPEs to raise alarms and send events when any fault occurs. The fault management module can be enhanced to support the SNMP trap facility. With the SNMP trap facility, DPE receives the events from the CPEs and converts them into SNMP traps. DPE further sends these SNMP traps to the trap receiver.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

4-21

Configuring SNMP Trap for CPEs

The following components are configured in Cisco BAC for SNMP Trap facility:

• RDU, see Configuration at RDU Level, page 4-22

• DPE and Trap Receiver, see Configuration at DPE Level, page 4-22

• Device, see Configuration at Device Level, page 4-23

Configuration at RDU Level

To configure RDU for SNMP trap facility:

Step 1 Create or update the BAC configuration template to support expedited and queued alarms.

The following parameters must be set in the configuration template:

• For expedited alarms:

• For Queued alarms

Chapter 4 CPE Management Overview

–

FAPService.{i}.FaultMgmt.SupportedAlarm.{i}.ReportingMechanism=0 {Expedited}

–

FAPService.{i}.FaultMgmt.ExpeditedEvent=Active

–

FAPService.{i}.FaultMgmt.SupportedAlarm.{i}.ReportingMechanism=1 {Queued}

–

FAPService.{i}.FaultMgmt.QueuedEvent=Active

For information on how to author configuration template, see Authoring Configuration Templates,

page 5-14.

Step 2 Add this configuration template to the RDU database:

a. Log into the Cisco BAC admin UI.

b. Choose Configuration on the primary navigation bar.

c. Choose Files on the secondary navigation bar. The View Files page appears.

d. Click Add.

The Add Files page appears.

e. Choose Configuration Template from the File Type drop-down list.

f. Browse for the Source File Name.

g. Add the configuration template name in the File Name field.

h. Click Submit.

Step 3 Associate this configuration template with the required Class of Service. For details, see Configuring the

Class of Service, page 17-1.

Configuration at DPE Level

To configure DPE for SNMP trap facility:

4-22

Step 1 Configure the SNMP alarm property values in the DPE. The following alarm property values must be

configured in the DPE to support SNMP trap:

• AlarmIdentifier

• AlarmRaisedTime

• AlarmChangedTime

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 4 CPE Management Overview

• ManagedObjectInstance

• EventType

• ProbableCause

• SpecificProblem

• PerceivedSeverity

• AdditionalText

• AdditionalInformation

These SNMP alarm property values can be configured in dpe.properties file through DPE CLI. For details on DPE CLI, see Cisco Broadband Access Center 3.8 DPE CLI Reference.

Step 2 Customize the /cpeAlarm/alarmParams property in dpe.properties file to include SNMP alarm

property values. The SNMP alarm property values configured for this property are seen in the SNMP traps.

The default setting for /cpeAlarm/alarmParams property is:

/cpeAlarm/alarmParams=EventTime,AlarmIdentifier,EventType,ProbableCause,PerceivedSeverity

Step 3 Configure the trap receiver to receive the SNMP traps from the DPE. The trap receiver is added as SNMP

host with the required community and listening port. For information on how to add SNMP host and community, see Using the snmpAgentCfgUtil.sh Tool, page 11-6.

Configuring SNMP Trap for CPEs

Note You can configure multiple trap receivers to receive SNMP traps from the CPEs.

Configuration at Device Level

To configure the device for SNMP trap facility:

Step 1 Modify the device property hierarchy to include the following properties:

• /IPDevice/cpeAlarmTable

• /IPDevice/cpeAlarm/prefixEID

• /IPDevice/cpeAlarm/prefixCustomProp

Table 4- 3 provides the significance of these properties along with the possible and default values.

Table 4-3 Properties - SNMP Trap Facility

Possible

Property

values

/IPDevice/cpeAlarmTable None/Queued/

Expedited

Default Values Description

None None – BAC will not process any alarms in

the inform.

Queued – BAC will fetch all the alarms from Queued alarm table in the inform and send traps.

OL-27172-01

Expedited – BAC will fetch alarms from Expedited alarm table in the inform and send traps.

Cisco Broadband Access Center 3.8 Administrator Guide

4-23

Configuring SNMP Trap for CPEs

Table 4-3 Properties - SNMP Trap Facility (continued)

Chapter 4 CPE Management Overview

Property

Possible values

Default Values Description

/IPDevice/cpeAlarm/prefixEID True/False False If set to true, then EID will be prefixed

with ManagedObject Instance and AlarmIdentifier.

/IPDevice/cpeAlarm/prefixEID Any Custom

Property

- If set, then the custom property will be prefixed with the ManagedObject Instance in the SNMP trap.

For details on how to add these properties in the device property hierarchy, see Modifying Device

Records, page 16-11.

Step 2 Configure these properties to be available in /IPDevice/properties/available/pg.

Step 3 Perform a force synchronization of the device with the DPE to update the device configuration. For

details, see Forcing a Configuration Synchronization, page 16-17.

Step 4 Reboot the device and verify if the trap receiver receives the SNMP traps from the DPE.

The SNMP trap consists of the alarm property values. Tab le 4-4 describes the OIDs (Object Identifiers) that are used in device MIB for these SNMP alarm property values.

Table 4-4 OID mapping

OID .FaultMgmt.ExpeditedEvent.{i}. .FaultMgmt.QueuedEvent.{i}.

cenAlarmInstanceID AlarmIdentifier AlarmIdentifier

cenAlarmTimestamp EventTime EventTime

cenAlarmManagedObject

ManagedObjectInstance ManagedObjectInstance

Class

cenAlarmDescription EventType EventType

cenUserMessage1 ProbableCause ProbableCause

cenUserMessage2 SpecificProblem SpecificProblem

cenAlarmSeverity/cenAlar

PerceivedSeverity PerceivedSeverity

mSeverityDefinition

cenUserMessage3 AdditionalText AdditionalText

cenUserMessage3 AdditionalInformation AdditionalInformation

cenAlarmStatusDefinition NotificationType NotificationType

cenAlarmType unknown(1), direct(2),

indirect(3), mixed(4)

unknown(1), direct(2), indirect(3), mixed(4)

cenAlarmServerAddress DPE address DPE address

4-24

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Overview

CHAP T ER

Configuration Templates Management

This chapter details the templates that Cisco Broadband Access Center (BAC) supports for device configuration and device management.

This chapter includes the following sections:

• Overview, page 5-1

• Features of Cisco BAC Templates, page 5-4

• Authoring Configuration Templates, page 5-14

• Using the Configuration Utility, page 5-22

Cisco BAC provides an extensible template-based mechanism to assign configurations for devices that are compliant with the CPE WAN Management Protocol (CWMP). This template-processing mechanism simplifies configuration management, enabling customized configurations for millions of customer premises equipment (CPE) by using a small number of templates.

The result of processing a template is an instruction, which is forwarded to the DPEs in a device's provisioning group. This instruction contains all the necessary information for the DPE to configure the device.

Before attempting to create your own template file, familiarize yourself with information on:

OL-27172-01

• Parameter dictionaries (see Parameter Dictionaries, page 7-1)

• Firmware templates (see Firmware Management, page 6-1)

By using Cisco BAC templates, you can create a template file in an easily readable format, and edit it quickly and simply. You must add template files to the RDU by using the administrator user interface or the API, before any Class of Service can reference it.

Cisco BAC templates are XML documents written according to a published schema. When instructions are generated for a given device at the RDU for distribution to DPEs, a common template processor retrieves a template by using the device’s Class of Service object.

It then evaluates the template values, such as Includes and Conditionals, and substitutes template variables with their values. The resulting output is an XML object which represents a processed template.

Cisco Broadband Access Center 3.8 Administrator Guide

5-1

Overview

Chapter 5 Configuration Templates Management

The syntax and content of the processed configuration template is validated when it is added to the Cisco BAC system, ensuring that the XML template is well-formed. This validation also ensures that parameter names and values are consistent with definitions in the parameter dictionary, an XML file that defines the supported objects and parameters. (See Parameter Dictionaries, page 7-1.)

Note This type of validation occurs only when a template is added to the system or when the content of an

existing template is replaced

Cisco BAC uses the XML schemas that are defined in various files to generate instructions for device configurations. Table 5-1 lists these files and their locations.

Table 5-1 Files Used in Configuration Template Processing

File Purpose Options Available in Cisco BAC

Configuration Template Samples

Configuration Template Schema

Parameter Dictionary

Defines device configuration Sample templates

Sample templates are located at:

<BPR_HOME>/rdu/samples/cwmp

Validates configuration template syntax Default template schemas

Default template schemas are located at:

• CWMP configuration schema

<BPR_HOME>/rdu/templates/cwmp/schema/CwmpTemplateConstructs.xsd

• Common template schema

<BPR_HOME>/rdu/templates/cwmp/schema/CommonTemplateConstructs.xsd

Validates configuration template content Default dictionaries

Custom dictionaries

Default dictionaries are located at:

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr069-cwmp-dictionary.xml

5-2

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr098-cwmp-dictionary.xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr104-cwmp-dictionary.xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr106-cwmp-dictionary.xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr196-cwmp-dictionary-v1.1.xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr196-cwmp-dictionary-v2.0.xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr196-cwmp-dictionary-IGD-v1.1.

xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr196-cwmp-dictionary-IGD-v2.0.

xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/basic-cwmp-dictionary.xml

Parameter Dictionary Schema

Validates parameter dictionary syntax Default dictionary

Parameter dictionary schema is located at:

Schema for TR-069, TR-098, TR-104, TR-106, TR-181, and TR-196 dictionaries <BPR_HOME>/rdu/templates/cwmp/schema/TemplateDictionarySchema.xsd

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 5 Configuration Templates Management

Cisco BAC supports multiple instance object which is available in the configuration template. This facilitates discovering and updating parameters for the selective object instances without specifying the object instance number. For more information on multi-instance object support see, Multi-Instance

Object Support, page 4-5.

You can manage template files, configuration and firmware rules, by using the administrator user interface.

Overview

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

5-3

Features of Cisco BAC Templates

cwmp:ParameterDictionaries cwmp:ParameterDictionary

attributes

cwmp:Prerequisites

Configuration

This is the root element. This can have one or more ObjectInstances.

1..

cwmp:Notification

1..

tc:include

cwmp:ObjectInstance

cwmp:AccessControl

This represents an instance of a CPE node. The attribute "name" is mandatory and represents name of this node instance. Name of the ObjectInstance is validated using dictionary.

Indicates whether the CPE should include changed values of the specified parameter in the Inform message, and whether the CPE must initiate a session to the ACS when the specified parameter(s) change their value.

Array of zero or more entries for which write access to the specified Parameter is granted. If there are no entries, write access is only allowed from an ACS.

Parameter element describes a CPE Parameter. It must have a Value, Notification, or ToBeSigned tag.

cwmp:Parameter

tc:if

tc:choose

0..

cwmp:ObjectInstance

Features of Cisco BAC Templates

A configuration template is a collection of Objects and Parameters. In a TR-069 device, InternetGatewayDevice is the root object, while in TR-106 device, Device is the root object. In a TR-196 device, InternetGatewayDevice or Device is the root object.

Figure 5-1 illustrates the schema of a TR-069 device Configuration. Each element featured in the schema

is described in subsequent sections.

Figure 5-1 Configuration Schema

Chapter 5 Configuration Templates Management

5-4

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 5 Configuration Templates Management

A configuration template comprises the following components:

• ObjectInstance—Represents an instance of a TR-069 CPE node. You must specify the object’s

‘name.’

An object may include other objects and parameters, both of which, in turn, may include other elements in line with the TR-069 specification.

A CPE object may contain:

–

Object—Describes an instance of a CPE node.

–

Parameters—Describes a CPE parameter and must have a value, and Notification, Access Control, or both. (See Parameters, page 5-6.)

–

Notification—Enables notification of changes in the value on all child parameters of this parameter at all levels. (See Notification, page 5-8.)

–

Access Control—Controls whether or not entities other than the autoconfiguration server (user, SNMP, UPnP, and so on) can change values of any configuration parameters under this object. (See Access Control, page 5-9.)

• Parameter Dictionary—Contains definitions used to validate the objects and parameters in

configuration templates. Cisco BAC supports only one dictionary per template. (See Parameter

Dictionaries, page 7-1.)

• Prerequisites—Optionally, indicates the conditions that must be met before a device can be

configured. These conditions may include:

–

MaintenanceWindow—Enables you to specify the time that a configuration is to be applied to a device.

Features of Cisco BAC Templates

–

Expressions—Enable you to specify any parameters that need to match on the device as a prerequisite to applying the configuration; for example, a particular software or hardware version of a device.

See Figure 5-3 for a graphical representation of the prerequisite schema. For detailed information on using the prerequisite option, see Prerequisites, page 5-9.

Adding a configuration template to Cisco BAC would fail if there are errors in the template. To avoid configuration errors, ensure that all:

• Object names and parameter names exist in the parameter dictionary.

• Parameter values are of the type specified in the parameter dictionary.

• Parameters that are not writable do not have a value. However, they may have the Notification,

Access Control attributes, or both set.

• Substitutable variables are defined in the system through Cisco BAC custom property or device

property.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

5-5

Features of Cisco BAC Templates

158271

cwmp:Parameter

Parameter element describes a CPE Parameter. It must have a Value, Notification, or ToBeSigned tag.

Name is the name of a CPE Parameter. This is validated using parameter dictionary.

Value is data for the Parameter. Data type is validated using parameter dictionary.

cwmp:Name

ComplexValue is data for the Parameter.

cwmp:Value

cwmp:ComplexValue

cwmp:Notification

Array of zero or more entities for which write access to the specified Parameter is granted. If there are no entries, write access is only allowed from an ACS.

cwmp:AccessControl

Parameters

Chapter 5 Configuration Templates Management

This section describes the schema associated with parameter objects in the configuration templates (see

Figure 5-2).

Figure 5-2 Parameter Schema

The CPE parameter contains a name-value pair:

The name identifies the parameter, and has a hierarchical structure similar to files in a directory, with each level separated by a dot (.). Each level corresponds to an object instance: Some objects have a single instance or singletons, other objects have multiple instances. The parameter lists for both object instances are described in subsequent sections.

The value of a parameter may be one of several data types defined in the TR-069 specification. These data types are string, int, unsignedInt, boolean, dateTime, and base64, each of which is validated by a parameter dictionary (see Tab le 7 - 1 for data type definitions).

5-6

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 5 Configuration Templates Management

Example 5-1 illustrates how you can configure values for a parameter:

Example 5-1 Configuring Parameter Values

<Configuration> <ParameterDictionaries> <ParameterDictionary>tr069-cwmp-dictionary.xml</ParameterDictionary> </ParameterDictionaries> <ObjectInstance name="InternetGatewayDevice"> <ObjectInstance name="ManagementServer"> <Parameter> <Name>PeriodicInformEnable</Name> <Value>true</Value> </Parameter> <Parameter> <Name>PeriodicInformInterval</Name> <Value>86400</Value> </Parameter> </ObjectInstance> </ObjectInstance> </Configuration> </tc:Template>

Features of Cisco BAC Templates

Parameter List for Single Instance Object

This is an example of a single instance, or singleton:

InternetGatewayDevice.UserInterface.

The parameters of a singleton can be represented as:

InternetGatewayDevice.UserInterface.PasswordRequired = true InternetGatewayDevice.UserInterface.ISPName = SBC

Parameter List for Multiple Instance Objects

The TR-069 specification defines some objects that can have multiple instances, with each instance assigned a number. You use the parameter dictionary to define the objects that can have multiple instances.

For example,

Two instances of that object can be represented as described:

InternetGatewayDevice.Layer3Forwarding.Forwarding.1.Enable = true InternetGatewayDevice.Layer3Forwarding.Forwarding.2.Enable = false

Note Instance numbers are generated by the device. A parameter dictionary uses {i} to represent the objects

which can have multiple instances. Configuration templates must use the actual instance number to indicate the object which is being modified, such as

WANConnectionNumberOfEntries.

InternetGatewayDevice.Layer3Forwarding.Forwarding is a multiple instance object.

InternetGatewayDevice.WANDevice.1.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

5-7

Features of Cisco BAC Templates

Notification

Chapter 5 Configuration Templates Management

By using the Cisco BAC Notification attribute, a device can notify the DPE of parameter value changes. Notifications, by default, are turned off.

If Notification is enabled, it specifies that a device should include the changed values of a particular parameter in the device Inform message to the DPE, and that the device must initiate a session to the DPE whenever the value of that particular parameter is changed.

Cisco BAC supports the following values for the Notification attribute as defined in the TR-069 specification:

• Off—Notification set to off.

The device need not inform Cisco BAC of a change to the specified parameter(s).

• Passive—Notification set to Passive.

Whenever the specified parameter value changes, the device must include the new value in the ParameterList in the Inform message that is sent the next time that Cisco BAC establishes a session.

• Active—Notification set to Active.

Whenever the specified parameter value changes, the device must initiate a session with Cisco BAC, and include the new value in the ParameterList in the associated Inform message. Whenever a parameter change is sent in the Inform message due to a nonzero Notification setting, the Event code

4 VALUE CHANGE must be included in the list of Events.

Note The device returns a notification request rejected error if an attempt is made to set Notification on

a parameter deemed inappropriate; for example, a continuously varying statistic.

Configuring Notification

The following example illustrates how you can configure the Notification attribute.

In this example, a configuration file is defined and generated for a Notification set to it to

Passive.

UserInterface object, with

Active for all parameters. The ISPName parameter overrides this Notification and sets

<Notification>Active</Notification> <!-- applies to all parameters under this

object -->

<Name>PasswordRequired</Name>

<Name>WarrantyDate</Name>

<Name>ISPName</Name>

<Notification>Passive</Notification>  </Parameter> <Parameter>

<Name>ISPHomePage</Name>

5-8

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 5 Configuration Templates Management

</Parameter>

</ObjectInstance>

Access Control

Access control in Cisco BAC is enabled through the AccessControl attribute of the CPE that you can control by using configuration templates. CPE parameters can be changed using LAN autoconfiguration protocol if access control is set to allow such access. For instance, if the AccessControl attribute is set to

Subscriber, then the subscriber on the LAN can change the parameter value.

The value of the AccessControl attribute is an array of zero or more entities for which specific parameter is granted. If no entries are present, only updates to the parameter value are allowed from Cisco BAC.

Cisco BAC defines only one entity in this list, in line with the TR-069 specification: Subscriber. This enables Configuration protocol or through the UPnP protocol.

write access by the subscriber on the LAN, such as through the LAN-side DSL CPE

Features of Cisco BAC Templates

write access to a

Configuring Access Control

The following example illustrates how to set access control in Cisco BAC by using configuration templates:

under it -->

</ObjectInstance>

Prerequisites

Cisco BAC templates include a prerequisites option, which indicates what conditions must be met before configuring the device. For example, a prerequisite may specify that the device to which you apply a configuration must meet the requirement of a specific hardware or software version.

Prerequisite rules are embedded into an instruction, which is sent to the DPE. The DPE then interrogates the device as necessary to determine if the prerequisites match.

<AccessControl> <!--Allow LAN-side updates of this object and parameters

<Entity>Subscriber</Entity> </AccessControl> <Parameter>

<Name>PeriodicInformEnable</Name> <Value>true</Value>

</Parameter>

<Name>PeriodicInformEnable</Name> <AccessControl/>

</Parameter>

</ObjectInstance>

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

5-9

Features of Cisco BAC Templates

cwmp:Prerequisites

ParameterName is the full name of a CPE Parameter. This is validated using parameter dictionary.

This represents the time window when this configuration can be applied to a device.

This is Time of Day: hh:mm:ss. [ 13:04:05 ]

cwmp:MaintenanceWindow

0..7

cwmp:DayOfWeek

cwmp:Duration

hh:mm

This is Day of week when the configuration is applicable. Absence of this tag indicates that MaintenanceWindow is applicable to all days of week.

cwmp:Expression

This represents a condition that must be met before this configuration can be applied to a device.

cwmp:StartTime

cwmp:Value

Value is data for the Parameter. Data type is validated using parameter dictionary.

cwmp:InformParameterName

cwmp:ParameterName

This specifies either RequestDownload.FileType or RequestDownload.FileTypeArg\* . Values for these parameters may be provided by CPE when it requests a download.

cwmp:RpcArgumentName

0..

1..

cwmp:Operator

Figure 5-3 illustrates the schema of the prerequisites option:

Figure 5-3 Prerequisite Schema

Chapter 5 Configuration Templates Management

5-10

You use prerequisites to manipulate configuration generation through:

• Expressions

• MaintenanceWindow

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 5 Configuration Templates Management

Expressions

Expressions are conditionals that use information from device properties. They may use Parameters, InformParameters or rpcArguments. Expressions are used within prerequisites and firmware rules and are processed when a device contacts Cisco BAC to retrieve its configuration.

If the expressions that you specify evaluates to true, the condition(s) is met, and the corresponding configuration or firmware rule is applied to the device. For detailed information, see Using Conditionals,

page 5-19.

The Prerequisites tag may contain zero or more expressions.

SendHttpErrorOnFail

When the prerequisites specified in the configuration template are not met, and the sendHttpErrorOnFail attribute is set, an HTTP error with the specified code is sent to the device, and the corresponding configuration is not applied to the device.

Example 5-2 Configuring Prerequisite - sendHttpErrorOnFail

In this example, when the software version of the device is not 1.1, an HTTP error code is sent to the device.

<ParameterName>InternetGatewayDevice.DeviceInfo.SoftwareVersion</ParameterName> <Value>1.1</Value> <Operator>match</Operator>

</Expression>

</Prerequisites>

Features of Cisco BAC Templates

MaintenanceWindow

Use the MaintenanceWindow setting to specify the time window within which you want to apply a particular configuration to a specific CPE. This evaluation is performed at the DPE on device contact; as such, the DPE local time is used.

Note You should configure the server on which the DPE runs with automatic time server synchronization, such

as NTP.

MaintenanceWindow comprises:

• StartTime—Specifies a time value indicating the beginning of a maintenance window. This value is

• Duration—Specifies a time value indicating the duration from StartTime when the configuration can

• DayOfWeek—Specifies the days of the week when you can apply the configuration. Absence of this

You can use these elements to specify the time window when this rule can run, thus providing the ability to limit configuration upgrades to late in the night when subscribers are most likely sleeping.

The Prerequisites tag may contain zero or one MaintenanceWindow.

defined as hh:mm:ss.

be applied. This value is defined as hh:mm.

tag indicates that the rule is valid for all days of the week. This tag is optional.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

5-11

Features of Cisco BAC Templates

Example 5-3 Configuring MaintenanceWindow

In the following example, the values of the StartTime, Duration, and DayOfWeek tags define the period when this rule is in effect. This template takes effect at 1 a.m. for a period of 5 hours, on every Monday, Tuesday, and Friday.

Device Contact During MaintenanceWindow

A key concept in MaintenanceWindow is ensuring that devices contact Cisco BAC during the window.

You can configure the devices to contact the DPE at a given date and time, by setting a value for the PeriodicInformTime variable in the configuration template. Also, set the RandomDateTimeInRange tag to designate a time range when the device can contact Cisco BAC.

Chapter 5 Configuration Templates Management

<StartTime>01:00:00</StartTime> <Duration>05:00</Duration> <DayOfWeek>Monday</DayOfWeek> <DayOfWeek>Tuesday</DayOfWeek> <DayOfWeek>Friday</DayOfWeek>

</MaintenanceWindow>

See Example 5-4 for how to configure a device to contact Cisco BAC during a MaintenanceWindow.

Example 5-4 Configuring Device to Contact Cisco BAC During MaintenanceWindow

In the following example, the device contacts Cisco BAC for the first time on January 1, 2007, between 3 a.m. and 4 a.m. After the initial contact, the device continues to contact Cisco BAC every 30 minutes.

• PeriodicInformEnable is set to true to indicate that the device must periodically send device

information to Cisco BAC using the Inform method call.

• PeriodicInformInterval is set to 30 minutes (1800 seconds), requesting the device to attempt to

contact Cisco BAC every 30 minutes. This duration is the interval within which the device attempts to connect with Cisco BAC if

• PeriodicInformTime is set to a date and time when the device should initiate contact with Cisco

PeriodicInformEnable is true.

BAC.

</ObjectInstance>

<Name>PeriodicInformEnable</Name>

<Name>PeriodicInformInterval</Name>

<Name>PeriodicInformTime</Name>

</RandomDateTimeInRange>

</ComplexValue>

</Parameter>

5-12

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 5 Configuration Templates Management

For detailed information on PeriodicInformInterval, see the Broadband Forum’s Technical Report on TR-069.

You can initiate a firmware upgrade in a similar fashion. Firmware upgrades are typically carried out only within a specific time range. After defining a firmware rule template with the MaintenanceWindow option set, associate the firmware rule template to a Class of Service object by using the administrator user interface.

After you finish this task, the firmware rule is pushed to the DPE. The DPE evaluates the firmware rule and ensures that the firmware upgrade is executed during the specific time.

Configuring Prerequisites

This section illustrates how to configure the prerequisite option.

Example 5-5 Configuring Prerequisites - Maintenance Window

In this example, the prerequisite indicates that this template will come into effect at 1 a.m. for a duration of 5 hours. During this time, this template can be applied to any device that contacts Cisco BAC and has an

EventCode of 1 BOOT and the manufacturer as Acme, Inc.

Features of Cisco BAC Templates

Example 5-6 Prerequisite Using Expression

<InformParameterName>InternetGatewayDevice.DeviceInfo.EventCode</InformParameterName> <Value>1 BOOT</Value> <Operator>match</Operator>

</Expression> <Expression>

<ParameterName>InternetGatewayDevice.DeviceInfo.Manufacturer</ParameterName>

<Operator>matchIgnoreCase</Operator>

</Expression>

</Prerequisites>

Example 5-7 Prerequisite Using Regular Expression (Regex)

</MaintenanceWindow> <Expression>

<InformParameterName>Inform.EventCode</InformParameterName> <Value>^[0-9]\s\w</Value> <Operator>regexMatch</Operator>

</Expression>

</Prerequisites>

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

5-13

Authoring Configuration Templates

You can use Cisco BAC to generate instructions for customized configurations for many devices from a single template by using template constructs. Parameter substitution and conditional inclusion or exclusion of template content, controlled by values from the Cisco BAC property hierarchy, create a custom configuration from a template. A template may include other templates, providing a mechanism to reuse common configurations.

You must add template files to the RDU by using the administrator user interface or the API, before any Class of Service can reference it.

Note The XML elements in a template are divided into two groups:

• Elements that are not prefixed by tc are unique to configuration templates.

• Elements prefixed by tc are generic constructs that are the same for configuration templates and for

firmware rule templates.

A configuration template, with Configuration as the root element, must follow a structure similar to

Example 5-8.

Chapter 5 Configuration Templates Management

Example 5-8 Sample Configuration Template

<ParameterName>InternetGatewayDevice.DeviceInfo.Manufacturer</ParameterName>

<Operator>matchIgnoreCase</Operator> </Expression>

</Prerequisites> <Configuration> <ParameterDictionaries> <ParameterDictionary>tr069-cwmp-dictionary.xml</ParameterDictionary> </ParameterDictionaries> <ObjectInstance name="InternetGatewayDevice"> <ObjectInstance name="ManagementServer"> <Parameter> <Name>PeriodicInformEnable</Name> <Value>true</Value> </Parameter> <Parameter> <Name>PeriodicInformInterval</Name> <Value>86400</Value> </Parameter> </ObjectInstance> </ObjectInstance> </Configuration> </tc:Template>

5-14

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 5 Configuration Templates Management

Configuration templates support:

• Parameter substitution—Substitutes values from the Cisco BAC property hierarchy into XML

element content and element attributes by using the

Parameter Substitution, page 5-16).

• Includes—Build a set of reusable template snippets. Includes are useful for defining options that are

common across many service classes without having to duplicate the options in several templates. (For details, see Using Includes, page 5-17.)

• Conditionals—Include or exclude blocks of text within a template. The text blocks that you can

enclose within the conditional statements are limited to parameter and object instance elements. (For details, see Using Conditionals, page 5-19.)

Custom Properties

Cisco BAC properties provide access to data that is stored in Cisco BAC using the API. Using the API, you can use the properties of corresponding objects to retrieve preprovisioned, discovered, and status data. You can use properties to configure Cisco BAC at the appropriate level of granularity (from system level to device group and to individual device). See Property Hierarchy, page 4-4 for details.

You can use custom properties to define additional customizable device information to be stored in the RDU database. You typically use these properties to substitute parameter values in configuration templates and firmware rule templates.

Authoring Configuration Templates

VAR() construct. (For details, see Using

The template parser works from the bottom up while locating properties in the hierarchy (device first, followed by the Group, provisioning group, then the Class of Service, device type, and system defaults) and converts the template option syntax.

For details on substituting template parameters using the

Example 5-9 Retrieving Username or Password from Device

VAR() construct, see the subsequent section.

The following example illustrates how you can use templates to retrieve properties from different levels; for instance, username and password credentials from a device.

<tc:Template>

<ParameterDictionary>tr069-cwmp-dictionary.xml</ParameterDictionary> </ParameterDictionaries> <ObjectInstance name="InternetGatewayDevice">

<Name>PeriodicInformEnable</Name>

<Name>PeriodicInformInterval</Name>

<Notification>Active</Notification> </Parameter> <Parameter>

<Name>ConnectionRequestUsername</Name>

<Value>VAR(name=/dt/username, defaultValue="User")</Value> </Parameter> <Parameter>

<Name>ConnectionRequestURL</Name>

<Value>VAR(name=/dt/pk, defaultValue="http://testURL")</Value> </Parameter>

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

5-15

Authoring Configuration Templates

</ObjectInstance>

</Configuration>

</tc:Template>

To configure custom properties from the administrator user interface, choose the Configuration > Custom Property tabs. Use the Add Custom Property page to add or delete custom properties. For

details, see Configuring Custom Properties, page 17-5.

Caution If you remove custom properties that a template references, the RDU fails to generate instructions for a

device.

Using Parameter Substitution

Values from the Cisco BAC property hierarchy are substituted into a template by using the VAR() construct, to produce a custom configuration from a configuration template. The VAR() construct can appear in an XML element value or element attribute. You can also use it to substitute full or partial values.

Chapter 5 Configuration Templates Management

Syntax Description

The following list describes the constructs that Cisco BAC supports for parameter substitution:

• Cisco BAC property value into XML element content

• Cisco BAC property value into XML element attribute

• Default value

• XML partial element content

• Values with special characters

VAR(token=someChar, name=someProperty, defaultValue=someValue)

• token—Specifies the character that delimits subsequent fields. This element is optional and defaults

to a comma (,).

Note If the default value contains a comma (,), then start the VAR() construct by specifying a token

character. This token must not appear in the default value. Also, ensure that the token character precedes the VAR end bracket.

• name—Specifies the name of the custom property to be substituted or the Standard Device

properties to be referenced.

• defaultValue—Specifies the value to use if the referenced property is not available.

5-16

Example 5-10 Setting a Value to a Cisco BAC Custom Property

<Value>VAR(name=/cpe/version, defaultValue=4)</Value>

Example 5-11 Referencing Standard Device Property

<Value>VAR(name=/IPDevice/connectionRequestPath, defaultValue="http://test")</Value>

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 5 Configuration Templates Management

Note The API constant for /IPDevice/connectionRequestPath is

IPDeviceKeys.CONNECTION_REQUEST_PATH.

Example 5-12 Using a defaultValue With a Comma

<Value>VAR(token=;;name=/cpe/usrStr; defaultValue=4,5;)</Value>

Example 5-13 Creating a String Value based on a Cisco BAC Property

<Value>CWMP_VAR(name=/cpe/version, defaultValue=4).bin</Value>

If cpe/version is 1-08 then the Value will be CWMP_1-08.bin.

Using Includes

Include files let you build a set of reusable template snippets. These files are useful for defining options that are common across many service classes without having to duplicate the options in several templates.

You can include the content of a particular file into a template by using the inserting the content of included files into the host template, the parameter dictionary that is specified in the host template validates the content of the resulting template.

Authoring Configuration Templates

tc:include construct. After

Note If included templates use objects and parameters not defined in the same dictionary as the host template,

parameter validation fails during instruction generation.

The tc:Include element specifies the href attribute, where href identifies the name of the Cisco BAC template file that is included in the host template. Use double quotation marks (") when using an include directive in template.

Note Ensure that Include files are of the same file type as the template. For instance, when adding a

configuration template, all the included files must be of the Configuration Template file type.

Example 5-14 Include Files

The following example displays the content of a host template, and an included template.

Included Template: informInterval.xml

<tc:Template :xsi="http://www.w3.org/2001/XMLSchema-instance" :tc="urn:com:cisco:bac:common-template" ="urn:com:cisco:bac:cwmp-template" :schemaLocation="urn:com:cisco:bac:common-template CommonTemplateConstructs.xsd">

<ParameterDictionary>tr069-cwmp-dictionary.xml</ParameterDictionary> </ParameterDictionaries> <ObjectInstance name="InternetGatewayDevice">

<Name>PeriodicInformEnable</Name> <Value>true</Value>

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

5-17

Authoring Configuration Templates

</Configuration>

</tc:Template>

Host Template: cwmp-config.xml

<tc:Template :xsi="http://www.w3.org/2001/XMLSchema-instance" :tc="urn:com:cisco:bac:common-template" ="urn:com:cisco:bac:cwmp-template" :schemaLocation="urn:com:cisco:bac:common-template CommonTemplateConstructs.xsd"> <Configuration>

Chapter 5 Configuration Templates Management

</Parameter> <Parameter>

<Name>PeriodicInformInterval</Name> <Value>30</Value>

</Parameter>

</ObjectInstance>

<ParameterDictionary>tr069-cwmp-dictionary.xml</ParameterDictionary> </ParameterDictionaries> <tc:include href="informInterval.xml"/> <ObjectInstance name="InternetGatewayDevice">

</Parameter>

</ObjectInstance> </ObjectInstance>

</Configuration>

</tc:Template>

Template After Inserting Included File: informInterval.xml

<tc:Template :xsi="http://www.w3.org/2001/XMLSchema-instance" :tc="urn:com:cisco:bac:common-template" ="urn:com:cisco:bac:cwmp-template" :schemaLocation="urn:com:cisco:bac:common-template CommonTemplateConstructs.xsd">

<ParameterDictionary>tr069-cwmp-dictionary.xml</ParameterDictionary> </ParameterDictionaries> <ObjectInstance name="InternetGatewayDevice">

<Name>PeriodicInformEnable</Name>

<Name>PeriodicInformInterval</Name>

</ObjectInstance> </ObjectInstance> <ObjectInstance name="InternetGatewayDevice">

</Parameter>

</ObjectInstance> </ObjectInstance>

5-18

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 5 Configuration Templates Management

</Configuration>

</tc:Template>

Using Conditionals

Cisco BAC supports powerful conditional expressions in template constructs to provide ultimate configuration customization.

You can use conditional expression constructs to include or exclude blocks of text within a template. These construct elements are tc:if, tc:choose, and tc:when. You use the tc:if construct for simple single conditionals.

You can use a combination of tc:choose, tc:when, and tc:otherwise for a logical if...else if...else construct. The tc:if and the tc:when constructs require a test attribute. A test attribute is an expression that can be evaluated, and the resulting object can be converted to a Boolean operator (true or false).

The tc:choose element selects one from a number of possible alternatives. This element contains a sequence of tc:when elements, followed by an optional tc:otherwise element. Each tc:when element has a single attribute, test, which specifies an expression.

The content of the tc:when and the tc:otherwise elements is a valid template segment. When a tc:choose element is processed, each of the tc:when elements is tested in turn, by evaluating the expression and converting the resulting object to a Boolean operator.

The content of the first—and only the first—tc:when element whose test is true is instantiated. If no tc:when is true, the content of the tc:otherwise element is instantiated. If no tc:when element is true and no tc:otherwise element is present, nothing is created.

Authoring Configuration Templates

Note Within expressions, you can use single (‘) or double quotes (“) to delimit literal strings. The template

processor interprets a quotation mark (‘ or “) as terminating the attribute. To avoid this problem, you can enter the marks as a character reference (" or '). (See Tab l e 5-2.) Alternatively, the expression can use single quotes (‘) if the attribute is delimited with double quotes (“) or vice-versa.

Table 5- 2 lists the conditional template constructs that this Cisco BAC release supports.

Table 5-2 Conditional Template Constructs Supported in Cisco BAC

Conditional statement If

Conditional statement If...else if...else

Conditional statement or

Conditional expression and

Conditional expression lessThan

Conditional expression lessThanEquals

Conditional expression greaterThan

Conditional expression greaterThanEquals

Conditional expression contains, notContains

Conditional expression containsIgnoreCase, notContainsIgnoreCase

Conditional expression equals, notEquals

Conditional expression equalsIgnoreCase, notEqualsIgnoreCase

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

5-19

Authoring Configuration Templates

Table 5-2 Conditional Template Constructs Supported in Cisco BAC (continued)

Conditional expression when..otherwise

Conditional expression choose

XML does not support the left angle bracket (<) and the ampersand (&). Instead, use the predefined entities (described in Table 5 - 3) for these characters.

Table 5-3 XML Definitions in Cisco BAC

Instead of ... Use ...

< (less than) <

<= (less than or equal) <=

> (greater than) >

>= (greater than or equals) >=

& (ampersand) &

' (apostrophe) '

" (double quotes) "

Chapter 5 Configuration Templates Management

The following examples illustrate various conditional expressions:

Example 5-15 Numerical Test Condition

Using 100 as a number:

<tc:if test="VAR(name=/cpe/version, defaultValue=20) greaterThan 100">

<Name>Enable</Name> <Value>false</Value>

</Parameter>

</tc:if>

Example 5-16 String Test Condition

Using 100 as string:

<tc:if test="VAR(name=/cpe/version, defaultValue=20) greaterThan '100'">

<Name>Enable</Name> <Value>false</Value>

</Parameter>

</tc:if>

Note When comparing digits as numbers, 20 is less than 100. However, when an operator is used with

a string, comparing digits as strings makes 20 greater than 100.

5-20

Example 5-17 Looking for Text in a Cisco BAC Property

Using text cwmp:

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 5 Configuration Templates Management

<tc:if test="contains(VAR(name=/cpe/UsrStr, defaultValue=linksys), 'cwmp')">

<Name>Enable</Name> <Value>false</Value>

</Parameter>

</tc:if>

Example 5-18 Looking for Text in Single Quotes

Using cwmp’s test:

<tc:if test="contains(VAR(name=/cpe/UsrStr, defaultValue=linksys), "cwmp's test")">

<Name>Enable</Name> <Value>false</Value>

</Parameter>

</tc:if>

Example 5-19 Looking for Text in Double Quotes

Using cwmp test:

<tc:if test="contains(VAR(name=/cpe/UsrStr, defaultValue=linksys), 'cwmp "test"')">

<Name>Enable</Name> <Value>false</Value>

</Parameter>

</tc:if>

The text blocks that you can enclose within the conditional statements are limited to Parameter and

Object elements.

Authoring Configuration Templates

Example 5-20 Choosing from Alternatives (Using choose and when Syntax)

The following example describes the syntax when using tc:choose and tc:when:

<tc:choose>

<tc:when test="VAR(name=/cpe/version,defaultValue=11) greaterThan 12">

<Name>UpgradeAvailable</Name> <Value>true</Value>

</Parameter> </tc:when> <tc:when test="VAR(name=/db/version,defaultValue=15) greaterThan 14">

<Name>UpgradeAvailable</Name> <Value>true</Value>

</Parameter> </tc:when> <tc:otherwise>

<Name>UpgradeAvailable</Name> <Value>false</Value>

</Parameter> </tc:otherwise>

</tc:choose>

Example 5-21 Choosing from Alternatives (Using choose and if Syntax)

The following example describes the syntax when using tc:choose and tc: if:

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

5-21

Using the Configuration Utility

Chapter 5 Configuration Templates Management

<tc:choose>

'true')">

</tc:choose>

<tc:if test="contains(VAR(name=FC-ACTIVATED-INFORM-ENABLE, defaultValue=false),

<Name>PeriodicInformInterval</Name> <Value>21600</Value>

</Parameter> </tc:if> <tc:else>

<Name>PeriodicInformInterval</Name> <Value>1200</Value>

</Parameter> </tc:else>

Using the Configuration Utility

You can use the configuration utility to test, validate, and view TR-069 template files: configuration and firmware rules. These activities are critical to successful deployment of instructions for individualized configuration files. (For more information on templates, see Authoring Configuration Templates,

page 5-14.)

The configuration utility is available only when the RDU is installed, and it is installed in the <BPR_HOME>/rdu/bin directory.

All examples in this section assume that the RDU is operating and that these conditions apply:

• The BAC application is installed in the default home directory (/opt/CSCObac).

• The RDU login name is bacadmin.

• The RDU login password is changeme.

Note Some of the examples provided in this section were truncated whenever the omitted formation is of no

consequence to the example of its outcome. Instances where this occurs are identified by an ellipsis (...) that precede the example summary.

This section discusses:

• Running the Configuration Utility, page 5-23

• Adding a Template to Cisco BAC, page 5-23

• Validating XML Syntax for a Local Template File, page 5-24

• Validating XML Syntax for a Template Stored in Cisco BAC, page 5-24

• Testing Template Processing for a Local Template File, page 5-25

• Testing Template Processing for a Template Stored in Cisco BAC, page 5-26

• Testing Template Processing for a Cisco BAC Template File and a Device, page 5-27

5-22

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 5 Configuration Templates Management

Running the Configuration Utility

In subsequent procedures and examples, the phrase running the configuration utility means to enter the runCfgUtil.sh command from the directory specified. To run the configuration utility, run this command from the <BPR_HOME>/rdu/bin directory:

runCfgUtil.sh options

The available options include:

• -cwmp—Specifies the input file is to be processed as a CWMP technology configuration template

file. Use -cwmp with the -a option.

• -a {sc | gc}—Specifies a required action, which could be either:

–

sc—To specify a syntax check to test if the XML template and dictionary are well-formed. Use sc with the –l option.

–

gc—To process a configuration template the same way as the Instruction Generation Service (IGS) would. Use gc with the (–l and –data), or the (-l and -i) options.

• -l filename—Identifies the input file to be on the local file system. For example, if the name of your

input file is any_file, enter -l any_file.

Using the Configuration Utility

Note Do not use -l with the -r option.

• -o filename—Saves the output of template processing in XML format into the specified file. For

example, to save the output in a file called op_file, enter -o op_file This is an optional element.

• -i device id—Specifies the device to use for variable substitution when processing the template.

Variable values are retrieved by using the device’s properties. Use with the -r option.

• -r filename—Specifies name of template stored in the RDU. Use this option instead of the -l option.

• -u username—Specifies the username to be used when connecting to the RDU.

• -p password—Specifies the password to be used when connecting to the RDU.

• -firmware—Specifies the input file to be a firmware rule template. Otherwise, assume configuration

template.

Adding a Template to Cisco BAC

To use the configuration utility to test BAC templates:

Step 1 Develop the template as described in Authoring Configuration Templates, page 5-14. If the template

includes other templates, make sure all the referenced templates are in the same directory.

Step 2 Run the configuration utility on the local file system. You can check the syntax for the template, or have

the configuration utility process template as IGS would, and return XML output.

If the processed template uses contain the defaultValues for those

Step 3 Add the template (and any included templates that are used) to the RDU.

VAR() constructs to reference a device property, the resulting output will

VAR() constructs.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

5-23

Using the Configuration Utility

If the template uses VAR() constructs to reference a device property, use the device option to generate a sample template.

Step 4 After all tests succeed, configure a Class of Service to use the template.

Validating XML Syntax for a Local Template File

Use the runCfgUtil.sh command to validate template files stored on the local file system.

Chapter 5 Configuration Templates Management

Syntax Description

Step 1 Change directory to /opt/CSCObac/rdu/samples/cwmp.

Step 2 Select a template file to use.

runCfgUtil.sh -cwmp -a sc -l file

• -cwmp—Identifies the input file to be processed as a CWMP template file.

• -a sc—Specifies a syntax check.

• -l—Specifies that the input file is on the local file system.

• file—Identifies the input template file being validated.

To use a template file that is on the local file system:

Note This example uses an existing template file called sample-cwmp-config.xml. The -cwmp option

is used because this is a CWMP template.Run the configuration utility by using this command:

/opt/CSCObac/rdu/bin/runCfgUtil.sh -cwmp -a sc -l sample-cwmp-config.xml

• -cwmp—Identifies the input file as a CWMP template file.

• -l—Specifies that the input file is on the local file system.

• sample-cwmp-config.xml—Identifies the input template file being validated.

After running the utility, results similar to these should appear:

Broadband Access Center Configuration Utility Version: 3.0, Revision: 1.26 validating configuration template sample-cwmp-config.xml... >sample-cwmp-config.xml is valid.

Validating XML Syntax for a Template Stored in Cisco BAC

Use the runCfgUtil.sh command to validate template files that are in the RDU database.

Syntax Description

Cisco Broadband Access Center 3.8 Administrator Guide

5-24

runCfgUtil.sh -cwmp -a sc -r file -u username -p password

OL-27172-01

Chapter 5 Configuration Templates Management

• -cwmp—Identifies the input file to be processed as a CWMP template file.

• -a sc—Specifies a syntax check.

• -r file—Identifies the input file as a file that has been added to the RDU.

• -u username—Specifies the username to use when connecting to the RDU.

• -p password—Specifies the password to use when connecting to the RDU.

To validate a template file that has been added to the RDU:

Step 1 Change directory to /opt/CSCObac/rdu/samples/cwmp.

Step 2 Select a template file to use.

Note This example uses an existing template file called sample-cwmp-config.xml. The -cwmp option

is used because a CWMP template is being used.

Step 3 Run the configuration utility by using this command:

./runCfgUtil.sh -cwmp -a sc -r sample-cwmp-config.xml -u admin -p changeme

Using the Configuration Utility

• sample-cwmp-config.xml—Identifies the input file.

• admin—Identifies the username.

• changeme—Identifies the password.

• -cwmp—Identifies the file as a CWMP template.

After running the utility, results similar to these should appear:

Broadband Access Center Configuration Utility Version: 3.0, Revision: 1.26 validating configuration template sample-cwmp-config.xml... >sample-cwmp-config.xml is valid.

Testing Template Processing for a Local Template File

Use the runCfgUtil.sh command to test template processing for a local template file.

Syntax Description

runCfgUtil.sh -cwmp -a gc -l file -o file

• -cwmp—Identifies the input file to be processed as a CWMP template file.

• -a gc—Specifies instructions for configuration generation.

OL-27172-01

• -l file—Specifies that the input file is on the local file system.

• -o file—Specifies that the processed template be saved in XML format into the specified file.

To test template processing for a local template file:

Step 1 Change directory to /opt/CSCObac/rdu/samples/cwmp.

Step 2 Select a template file to use. This example uses the existing template file, sample-cwmp-config.xml.

Cisco Broadband Access Center 3.8 Administrator Guide

5-25

Chapter 5 Configuration Templates Management

Using the Configuration Utility

Step 3 Run the configuration utility by using this command:

./opt/CSCObac/rdu/bin/runCfgUtil.sh -cwmp -a gc -l sample-cwmp-config.xml -o output.xml

• sample-cwmp-config.xml—Identifies the input file.

• output.xml—Identifies the file in which to save the processed template in XML format.

After running the utility, results similar to these should appear:

Broadband Access Center Configuration Utility Version: 3.0, Revision: 1.26 generating configuration from sample-cwmp-config.xml... output.xml generated successfully.

You can view the configuration from the output.xml file.

Testing Template Processing for a Template Stored in Cisco BAC

Use the runCfgUtil.sh command to test the template processing for a template in the RDU database.

Syntax Description

Step 1 Change directory to /opt/CSCObac/rdu/samples/cwmp.

Step 2 Select a template file to use. This example uses the existing template file, sample-cwmp-config.xml.

Step 3 Run the configuration utility by using this command:

runCfgUtil.sh -cwmp -a gc -r file -o file -u username -p password

• -cwmp—Identifies the input file to be processed as a CWMP template file.

• -a gc—Specifies instructions for configuration generation.

• -r file—Identifies the input file as a file that has been added to the RDU.

• -o file—Specifies that the processed template be saved in XML format into the specified file.

• -u username—Specifies the username to use when connecting to the RDU.

• -p password—Specifies the password to use when connecting to the RDU.

To test the template processing for a template stored in Cisco BAC:

./runCfgUtil.sh -cwmp -a sc -r sample-cwmp-config.xml -o output.xml -u admin -p changeme

• sample-cwmp-config.xml—Identifies the input file.

• output.xml—Identifies the file in which the generated configuration is to be saved in XML format.

After running the utility, results similar to these should appear:

Broadband Access Center Configuration Utility Version: 3.0, Revision: 1.26 generating configuration from sample-cwmp-config.xml... output.xml generated successfully.

5-26

You can view the configuration from the output.xml file.

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 5 Configuration Templates Management

Using the Configuration Utility

Testing Template Processing for a Cisco BAC Template File and a Device

Use the runCfgUtil.sh command to test the template processing for a file stored in the RDU database and associated with a device.

Syntax Description

Step 1 By using the administrator user interface, add the template file

Step 2 Select a template file to use. This example uses the existing template file, sample-cwmp-var-config.xml.

Step 3 Identify a device that is already in Cisco BAC and use that device’s ID. This example uses a device with

runCfgUtil.sh -cwmp -a gc -r file -o file -i deviceID -u username -p password

• -cwmp—Identifies the input file to be processed as a CWMP template file.

• -a gc—Specifies instructions for configuration generation.

• -r file—Identifies the input file as a file that has been added to the RDU.

• -o file—Specifies that the processed template be saved in XML format into the specified file.

• -i deviceID—Specifies the device to use. Variable values are retrieved using the device properties.

• -u username—Specifies the username to use when connecting to the RDU.

• -p password—Specifies the password to use when connecting to the RDU.

To test the template processing for a file stored in the RDU and associated with a device:

/opt/CSCObac/rdu/samples/cwmp/sample-cwmp-var-config.xml to Cisco BAC.

Note The sample-cwmp-var-config.xml template has a reference to the

/IPDevice/connectionRequestUsername device property. The API constant for the property is

IPDeviceKeys.CONNECTION_REQUEST_USERNAME.

the /IPDevice/connectionRequestUsername property set to testUser.

OL-27172-01

Step 4 Identify the device to use. This example assumes that the device exists in the RDU and has the variables

set as properties.

Step 5 Run the configuration utility by using this command:

./runCfgUtil.sh -cwmp -a gc -r sample-cwmp-var-config.xml -i OUI-1234 -o output.xml -u admin -p changeme

• sample-cwmp-var-config.xml—Identifies the input file.

• OUI-1234—Identifies the ID of the device. The Device ID used here is for example purposes only.

• output.xml—Identifies the file in which to save the processed template in XML format.

• bacadmin—Identifies the default username being used in this example.

• changeme—Identifies the default password being used in this example

After running the utility, results similar to these should appear:

Broadband Access Center Configuration Utility Version: 3.0, Revision: 1.26 generating configuration from sample-cwmp-var-config.xml... output.xml generated successfully.

Cisco Broadband Access Center 3.8 Administrator Guide

5-27

Using the Configuration Utility

Note You can open the output.xml file to view the configuration. The

Chapter 5 Configuration Templates Management

VAR(name=/IPDevice/connectionRequestUsername, defaultValue=test) statement will be

replaced with testUser.

5-28

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Overview

CHAP T ER

Firmware Management

This chapter describes firmware management for TR-069 compliant devices in Cisco Broadband Access Center (Cisco BAC).

This chapter includes the following sections:

• Overview, page 6-1

• Firmware Management Mechanisms, page 6-2

• Managing Firmware Files, page 6-5

• Authoring Firmware Rules Templates, page 6-6

• Using Template Constructs with Firmware Rule Templates, page 6-13

Firmware management consists of maintaining and distributing sets of firmware image files to corresponding customer premise equipment (CPE) through the Cisco BAC system. A firmware rules template associates the firmware image files to groups of devices. Cisco BAC uses the rules in the associated firmware rules template to evaluate which firmware to download to the device.

The firmware management functionality allows the administrator to view firmware information on devices, to add firmware images to the database, and to apply the image files to specific devices.

Cisco BAC supports two mechanisms for CPE firmware management:

• Policy-based firmware management through firmware rules templates.

• Direct firmware management through device operations API.

See Firmware Rule Templates, page 6-2, and Direct Firmware Management, page 6-4, for detailed information.

In the process of firmware management, regardless of the management method used, the device is instructed to obtain a new firmware image file from a file server. Cisco BAC provides a file service in its DPE. However, you can also direct CPE to other file servers.

Firmware rules can apply firmware to devices, based on a match of any preprovisioned or discovered device parameters, including device group membership, model, type, current state, type of connectivity, and so on.

The DPE triggers the firmware download by issuing a Download RPC with the location of the file on a file server and authentication credentials, if any. Cisco BAC supports HTTP and HTTP over SSL, called SSL/TLS in this chapter, for file downloads on DPE servers.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

6-1

Firmware Management Mechanisms

This download can be initiated in various modes:

• Firmware-rule based, in which firmware rules may or may not allow the download of the file

requested by a device, or may download a different file. Firmware rules are executed whenever a device connects to the DPE.

• The device may contact the DPE, based on periodic contact after a reboot or a specific action, such

as an user-initiated upgrade by clicking in the local user interface of the device. Regardless of how the device contacts the DPE, the firmware rules, determine whether the upgrade is needed and is allowed at the time of the particular interaction.

• Proxy, in which an external application invokes the API download operation for a specific device

and specifies the firmware image file location. The DPE then executes the Download RPC on the device, causing the device to download the file from the specified location.

The download can occur in three ways:

–

Chapter 6 Firmware Management

Immediate, in which the DPE connects to the device and instructs the device to download the firmware.

On-connect, in which the DPE instructs the device to download the firmware on next contact with the device.

Asynchronous, in which the DPE instructs the device to download the firmware without reserving the PACE thread at RDU. The operation result is sent to the API client in an AyncOperationEvent.

The multiple instance object support is available in the firmware template, which facilitates discovering the device parameters for multiple object instances. The parameter value associated with the discovered object instances is matched with the parameter values specified in the template, and further firmware rule is applied based on the match condition. For more information on multi-instance object support, see

Multi-Instance Object Support, page 4-5.

Firmware Management Mechanisms

This section describes CPE firmware-management mechanisms provided by Cisco BAC. These comprise:

• Policy-based firmware management through firmware rules templates. See Firmware Rule

Templates, page 6-2, for detailed information.

• External firmware management through proxy operations. See Direct Firmware Management,

page 6-4, for detailed information.

Firmware Rule Templates

You use rule templates to set policy-based firmware management. The firmware rules templates are XML documents written according to a published schema document. Each template must be stored in a file and uploaded into Cisco BAC.

Each firmware rules template contains one or more rules which trigger firmware updates based on specific conditions. Any number of such templates can be added to Cisco BAC, through the administrator user interface or API. The template is associated with a Class of Service object using the

COS_CWMP_FIRMWARE_RULES_FILE property. Each device, in turn, is assigned to a Class of Service. (For

information on Cisco BAC object relationships, see Cisco BAC Device Object Model, page 4-2.)

6-2

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 6 Firmware Management

In this model, you can make convenient updates to the definition of the rules, which apply to a large number of devices. When the rules template is updated, CPE that are indirectly associated with the template through the Class of Service are managed according to the new policy.

When the device establishes a connection with Cisco BAC, its firmware and configuration are automatically synchronized based on the configuration and firmware rules cached at the DPE. First, the firmware rules are executed, and if appropriate, the device firmware is updated. Then, the device configuration is synchronized.

Earlier to this release, the only file type supported by Cisco BAC was "1 Firmware Upgrade Image". With this release of Cisco BAC, firmware download is enhanced to allow upgrade of CPE devices with different vendor specific TR-069 download file types. Now vendor can define file type in both internal and external firmware rule tag.

Cisco BAC provides a two-stage firmware rule processing. First, the templates are processed at the RDU where template constructs such as conditionals and substitutable parameters are interpreted (See Using

Template Constructs with Firmware Rule Templates, page 6-13).

This processing allows customization of rules for devices based on data available at the RDU (such as device properties and grouping). This data could be preprovisioned by using the API. Data previously discovered from the device and stored at the RDU can also be used in constructing the templates.

After the template has been processed, the resulting rules are sent to the DPEs in the device’s provisioning group. The rules, in turn, can have dynamic matching criteria, which enable further granularity in firmware rules policy.

To determine if a firmware update is needed, the rules engine at the DPE evaluates the firmware rules. Firmware rules allow a firmware update to be triggered on match of:

• Inform event types

Firmware Management Mechanisms

• Device RequestDownloadRPC arguments

• Inform parameter values

• Any other device parameter values

• MaintenanceWindow time

Note You can use the MaintenanceWindow option to schedule firmware downloads to a device.

For details, see Device Contact During MaintenanceWindow, page 5-12.

Together, these rules provide a powerful mechanism to create policy for managing firmware. For example, an administrator can write a rule that forces all devices of a certain model with a certain current firmware version to upgrade to a different firmware, during a specific service time window.

The DPE logs an entry for all cases of firmware selection by using rules. It also logs an entry if none of the rules match. This logging mechanism can be useful to track devices that have no firmware image file associated with them or if the device firmware is simply up to date.

Cisco BAC uses the XML schemas that are defined in various files to generate instructions for device configurations. Table 6- 1 lists these files and their locations.

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

6-3

Firmware Management Mechanisms

Table 6-1 Files Used in Firmware Rules Template Processing

File Purpose Options Available in Cisco BAC

Firmware Rules Template Samples

Firmware Rule Template Schema

Parameter Dictionary

Chapter 6 Firmware Management

Defines device configuration Sample templates

Sample templates are located at:

<BPR_HOME>/rdu/samples/cwmp

Validates firmware rules template syntax Default template schemas

Default template schemas are located at:

• Firmware rules template schema

<BPR_HOME>/rdu/templates/cwmp/schema/FirmwareTemplateSchema.xsd

• Common template schema

<BPR_HOME>/rdu/templates/cwmp/schema/CommonTemplateConstructs.xsd

Validates firmware rules template content Default dictionaries

Default dictionaries are located at:

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr069-cwmp-dictionary.xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr098-cwmp-dictionary.xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr104-cwmp-dictionary.xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr106-cwmp-dictionary.xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr196-cwmp-dictionary-v1.1.xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr196-cwmp-dictionary-v2.0.xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr196-cwmp-dictionary-IGD-v1.1.

xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/tr196-cwmp-dictionary-IGD-v2.0.

xml

• <BPR_HOME>/rdu/templates/cwmp/dictionary/basic-cwmp-dictionary.xml

Parameter Dictionary Schema

Validates parameter dictionary syntax Default dictionary

Parameter dictionary schema is located at:

Schema for TR-069, TR-098, TR-104, TR-106, TR-181, and TR-196 dictionaries <BPR_HOME>/rdu/templates/cwmp/schema/TemplateDictionarySchema.xsd

Direct Firmware Management

The Cisco BAC device operations API allows the OSS to execute operations on individual devices. Among other operations, Cisco BAC provides standard CWMP RPC operations.

Managing firmware using device operations API gives the OSS precise control over operations performed on CPE. The OSS issues specific API calls which correspond to remote procedure calls (RPCs) necessary for CPE firmware update.

For example, a Download RPC can be invoked on the device using a corresponding API call. This command contains the URL of the firmware image file that the device should download and, if necessary, authentication credentials.

6-4

For detailed information on device operations, see CWMP Device Operations, page 14-1.

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Chapter 6 Firmware Management

File Service

In the process of firmware management and regardless of which management method is used, the device is instructed to obtain a new firmware file from a file server. Cisco BAC provides a file service in its DPE servers. However, CPE can also be directed to other file servers if necessary. For the various configuration options that Cisco BAC supports, see CWMP Service Configuration, page 12-1.

Managing Firmware Files

Firmware file management comprises the management of firmware image files and firmware rule template files. This functionality allows the administrator or applications by using the API to add, delete, or replace firmware image files and firmware rule template files, and view and search firmware image files and file information.

You can manage firmware through the administrator user interface, or through the API. To manage firmware image file and firmware rule templates on the administrator user interface, choose Configuration > Files.

Firmware rule template files determine the firmware image for a device. These files are stored in the RDU database with the file type

Firmware image files are stored in the RDU database with file type file has a firmware version that is specified by using the firmware version information to evaluate firmware rules.

Managing Firmware Files

Firmware Rules Template.

Firmware File. Each firmware image

Firmware Version attribute. The DPE uses the

Note While firmware images are managed using the central server (RDU), they are automatically distributed

or deleted from the appropriate DPEs.

Firmware file management allows the following operations for each file type:

Table 6-2 Firmware File Management Operations

Firmware Image File Firmware Rules Template

Add Add

You can add a firmware rule template file to the system only if it is valid; otherwise, Cisco BAC displays error messages explaining the type of error in the template.

Delete

You cannot delete an existing firmware image file if it is referenced in a firmware rules template.

To successfully delete a firmware image file, remove the reference to the firmware file in the

Delete

You cannot delete a firmware rules template if it is referenced by a Class of Service.

To successfully delete a firmware rules template, remove the reference to the Class of Service.

firmware rules template.

Retrieve contents Retrieve contents

Retrieve file attributes, such as size, name, and

properties

OL-27172-01

Cisco Broadband Access Center 3.8 Administrator Guide

6-5

Authoring Firmware Rules Templates

Table 6-2 Firmware File Management Operations (continued)

Firmware Image File Firmware Rules Template

Replace contents and/or modify file attributes/properties

You can replace an existing firmware image file even if the file is associated to a firmware file template using the API. The administrator user interface, however, notifies of existing associations before replacing a firmware image file.

When a firmware image file’s contents are replaced, IGS regenerates firmware rules for each affected device and IGS distributes them to the DPEs in the device’s provisioning group. Subsequently, when the device contacts the DPE, new rules are executed.

Search by name, suffix, regex or file type -

- View templates in tabular form from the

Chapter 6 Firmware Management

Replace file contents, modify file attributes and properties, or both

administrator user interface

Authoring Firmware Rules Templates

Firmware rule templates in Cisco BAC are based on an XML schema file located at <BPR_HOME>/rdu/templates/cwmp/schema/FirmwareTemplateSchema.xsd.

Firmware rules execute after processing an Inform from the device. They are also triggered after the device issues a RequestDownload RPC.

A firmware rules template comprises:

• FirmwareTemplate—The root element, which can contain a Prerequisites tag, and one or more

named FirmwareRule elements.

Firmware rules are processed in order and, once a firmware rule matches, further rules are not processed.

–

TemplateVersion—A TemplateVersion attribute has been introduced to support the different firmware file types and the download of large firmware files. In the FirmwareTemplate configuration file, the template version must be set to 3.0 to enable multi-instance object support feature. If the template version is not provided or is set to 1.0, the new features will not work as expected.

• Prerequisites—Contains conditions which must be met before the rules listed in the firmware rule

template are processed. Prerequisites may contain zero or one MaintenanceWindow, and zero or more Expressions.

You can enable Expressions and MaintenanceWindow for firmware templates just as it is done for configuration templates.

–

MaintenanceWindow—Describes the time range within which the firmware rule template is valid for processing. For detailed information, see Prerequisites, page 5-9.

Templates appear in tabular form only if they do not include conditionals.

6-6

Cisco Broadband Access Center 3.8 Administrator Guide

OL-27172-01

Cisco OL-27172-01 User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Preface

Broadband Access Center Overview

Features and Benefits

Supported Technology

CWMP Technology

TR-196

Broadband Access Center Architecture

Cisco BAC Deployment

Architecture

Regional Distribution Unit

Device Provisioning Engines

DPE Extension

DPE Licensing

Provisioning Groups

Discovery of ACS URL

Provisioning Group Scalability

Cisco BAC Process Watchdog

SNMP Agent

Logging

Access Registrar

RADIUS

Cisco Network Registrar

DHCP

LeaseQuery

Configuration Workflows and Checklists

Component Workflows

RDU Checklist

DPE Checklist

Technology Workflows

RDU Configuration Workflow

Preregistering Device Data in Cisco BAC

DPE Configuration Workflow

Configuring CWMP Service on the DPE

Configuring HTTP File Service on the DPE

Configuring HTTP Auth Service on the DPE

Provisioning Group Configuration Workflow

Configuring Home Provisioning Group Redirection Service on the DPE

CPE Management Overview

CWMP Overview

Cisco BAC Device Object Model

Discovering CPE Parameters

Property Hierarchy

Custom Properties

Multi-Instance Object Support

Configuration Template

Firmware Rules Template

Parameter Discovery

Display Live Data Operation

Instance Sorting

Instruction Generation and Processing

Device Configuration Synchronization

Device Deployment in Cisco BAC

Preregistered Devices

Unregistered Devices

Initial Provisioning Flows

For Preregistered Devices

For Unregistered Devices

Assigning Devices to Provisioning Groups

Explicit Assignment

Automatic Membership

Combined Approach

Device Diagnostics

Configuring SNMP Trap for CPEs

Overview

Configuration Templates Management

Features of Cisco BAC Templates

Parameters

Parameter List for Single Instance Object

Parameter List for Multiple Instance Objects

Notification

Configuring Notification

Access Control

Configuring Access Control

Prerequisites

Expressions

MaintenanceWindow