TR-232 (Bulk Data Collection).pdf

TECHNICAL REPORT
© The Broadband Forum. All rights reserved.
TR-232
Bulk Data Collection
Issue: 1
Issue Date: May 2012

Bulk Data Collection TR-232 Issue 1
May 2012 © The Broadband Forum. All rights reserved 2 of 28
Notice
The Broadband Forum is a non-profit corporation organized to create guidelines for broadband
network system development and deployment. This Broadband Forum Technical Report has
been approved by members of the Forum. This Broadband Forum Technical Report is not
binding on the Broadband Forum, any of its members, or any developer or service provider. This
Broadband Forum Technical Report is subject to change, but only with approval of members of
the Forum. This Technical Report is copyrighted by the Broadband Forum, and all rights are
reserved. Portions of this Technical Report may be copyrighted by Broadband Forum members.
This Broadband Forum Technical Report is provided AS IS, WITH ALL FAULTS. ANY
PERSON HOLDING A COPYRIGHT IN THIS BROADBAND FORUM TECHNICAL
REPORT, OR ANY PORTION THEREOF, DISCLAIMS TO THE FULLEST EXTENT
PERMITTED BY LAW ANY REPRESENTATION OR WARRANTY, EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY:
(A) OF ACCURACY, COMPLETENESS, MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE;
(B) THAT THE CONTENTS OF THIS BROADBAND FORUM TECHNICAL REPORT
ARE SUITABLE FOR ANY PURPOSE, EVEN IF THAT PURPOSE IS KNOWN TO
THE COPYRIGHT HOLDER;
(C) THAT THE IMPLEMENTATION OF THE CONTENTS OF THE TECHNICAL
REPORT WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS,
TRADEMARKS OR OTHER RIGHTS.
By using this Broadband Forum Technical Report, users acknowledge that implementation may
require licenses to patents. The Broadband Forum encourages but does not require its members
to identify such patents. For a list of declarations made by Broadband Forum member
companies, please see http://www.broadband-forum.org. No assurance is given that licenses to
patents necessary to implement this Technical Report will be available for license at all or on
reasonable and non-discriminatory terms.
ANY PERSON HOLDING A COPYRIGHT IN THIS BROADBAND FORUM TECHNICAL
REPORT, OR ANY PORTION THEREOF, DISCLAIMS TO THE FULLEST EXTENT
PERMITTED BY LAW (A) ANY LIABILITY (INCLUDING DIRECT, INDIRECT, SPECIAL,
OR CONSEQUENTIAL DAMAGES UNDER ANY LEGAL THEORY) ARISING FROM OR
RELATED TO THE USE OF OR RELIANCE UPON THIS TECHNICAL REPORT; AND (B)
ANY OBLIGATION TO UPDATE OR CORRECT THIS TECHNICAL REPORT.
Broadband Forum Technical Reports may be copied, downloaded, stored on a server or
otherwise re-distributed in their entirety only, and may not be modified without the advance
written permission of the Broadband Forum.
The text of this notice must be included in all copies of this Broadband Forum Technical Report.

Issue History
Issue
Number
Approval
Date
Publication
Date
Issue
Editor
Changes
1 14 May 2012 29 June 2012 John Blackford, Pace Plc Original
Comments or questions about this Broadband Forum Technical Report should be directed to
info@broadband-forum.org.
Editor John Blackford Pace Plc
BroadbandHome™
WG Chairs
Greg Bathrick
Jason Walls
PMC Sierra
QA Cafe
Chief Editor Michael Hanrahan Huawei

TABLE OF CONTENTS
EXECUTIVE SUMMARY.......................................................................................................6
1 PURPOSE AND SCOPE...................................................................................................7
1.1 PURPOSE ......................................................................................................................7
1.2 SCOPE ..........................................................................................................................7
2 REFERENCES AND TERMINOLOGY..........................................................................8
2.1 CONVENTIONS..............................................................................................................8
2.2 REFERENCES ................................................................................................................9
2.3 DEFINITIONS.................................................................................................................9
2.4 ABBREVIATIONS.........................................................................................................10
3 TECHNICAL REPORT IMPACT.................................................................................11
3.1 ENERGY EFFICIENCY ..................................................................................................11
3.2 IPV6...........................................................................................................................11
3.3 SECURITY...................................................................................................................11
3.4 PRIVACY ....................................................................................................................11
4 BULK DATA COLLECTION SERVICE SPECIFICATION ......................................12
4.1 TITLE PAGE ................................................................................................................12
4.2 PREFACE ....................................................................................................................12
4.2.1 Contacts.................................................................................................................12
4.2.2 Acknowledgements.................................................................................................12
4.2.3 Abstract .................................................................................................................12
4.2.4 Change History......................................................................................................12
4.2.5 Table of Contents...................................................................................................12
4.3 INTRODUCTION...........................................................................................................13
4.3.1 Purpose .................................................................................................................13
4.3.2 Compatibility.........................................................................................................13
4.3.3 References .............................................................................................................13
4.3.4 Overview ...............................................................................................................14
4.4 USE CASE...................................................................................................................15
4.4.1 Basic Use Case ......................................................................................................15
4.4.2 CWMP Data Model ...............................................................................................16
4.5 DATA DEFINITIONS.....................................................................................................17
4.5.1 BulkDataReport.....................................................................................................17
4.5.2 Formal Definitions.................................................................................................19
4.6 SERVICE DEFINITION ..................................................................................................20
4.6.1 XML Schema..........................................................................................................20
4.6.2 Sample Instance Document ....................................................................................23
ANNEX A: IPDR THEORY OF OPERATION.................................................................24
A.1 INTRODUCTION...........................................................................................................24
A.2 IPDR NODES..............................................................................................................25

A.3 IPDR INTERFACES......................................................................................................25
A.4 RECOMMENDED DATA COLLECTION TECHNIQUES .......................................................26
A.5 IMPLEMENTATION GUIDELINES ...................................................................................26
A.5.1 IPDR Recorder Information...............................................................................26
A.5.2 IPDR Streaming Protocol Considerations..........................................................26
A.5.3 IPDR File Transfer Protocol Considerations .....................................................28
LIST OF FIGURES
Figure 1 – Operational View of Bulk Data Collection ...............................................................15
Figure 2 – IPDR Reference Architecture ...................................................................................24
Figure 3 – Simplified IPDR Architecture...................................................................................24
Figure 4 – IPDR Streaming Protocol Interaction Flow...............................................................27
LIST OF TABLES
Table 1 – IPDR Formal Data Definition ....................................................................................19
Table 2 – IPDR Interfaces .........................................................................................................25

Executive Summary
TR-232 presents an IPDR-based mechanism that allows Service Providers to efficiently collect a
potentially large amount of data from their entire CPE population on a regular basis. This bulk
data collection mechanism is built upon the IPDR standard as defined in TM Forum, instead of
the CWMP standard as defined in TR-069, as CWMP is designed to be a device management
protocol rather than a data collection protocol. So, by utilizing IPDR instead of CWMP the
management plane is not polluted and the transfer of the data is more efficient. Devices
supporting the IPDR-based bulk data collection mechanism will have the mechanism configured
via CWMP.

1 Purpose and Scope
1.1 Purpose
Service Providers have the desire to use data available on their CPE population to analyze their
deployed services, collect trending information about specific CPE, and proactively identify
network problems before they cause subscriber churn. The following three statements
summarize the problem being addressed by this Technical Report.
1) Service Providers have a desire to reliably collect data from their CPE population on a
regular basis.
2) The data being collected is sizeable in nature and consists of statistics, performance data,
and other related parameters.
3) CWMP is an undesirable protocol for the collection of this data as it is not efficient or
flexible enough to meet the Service Provider’s needs.
The purpose of this Technical Report is to define a solution that allows for the collection of data
that resides on the Service Provider’s CPE population in an efficient and standard manner and to
reference IPDR as defined by TM Forum.
1.2 Scope
This Technical Report is intended to specify a complete solution that permits the collection of
bulk data from a Service Provider’s CPE population. In order to specify this solution, this
Technical Report will reference the existing IPDR protocol and data encodings. Furthermore,
this Technical Report will define an IPDR-relevant data format for use in the solution. Finally,
the content of this Technical Report will be formatted like an IPDR Service Specification, the
preferred documentation format of TM Forum.

2 References and Terminology
2.1 Conventions
In this Technical Report, several words are used to signify the requirements of the specification.
These words are always capitalized. More information can be found be in RFC 2119 [8].
MUST This word, or the term “REQUIRED”, means that the definition is an absolute
requirement of the specification.
MUST NOT This phrase means that the definition is an absolute prohibition of the specification.
SHOULD This word, or the term “RECOMMENDED”, means that there could exist valid
reasons in particular circumstances to ignore this item, but the full implications
need to be understood and carefully weighed before choosing a different course.
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" means that there could exist
valid reasons in particular circumstances when the particular behavior is acceptable
or even useful, but the full implications need to be understood and the case
carefully weighed before implementing any behavior described with this label.
MAY This word, or the term “OPTIONAL”, means that this item is one of an allowed set
of alternatives. An implementation that does not include this option MUST be
prepared to inter-operate with another implementation that does include the option.

2.2 References
The following references are of relevance to this Technical Report. At the time of publication,
the editions indicated were valid. All references are subject to revision; users of this Technical
Report are therefore encouraged to investigate the possibility of applying the most recent edition
of the references listed below.
A list of currently valid Broadband Forum Technical Reports is published at www.broadband-
forum.org.
Document Title Source Year
[1] TR-069 Amendment 4 CPE WAN Management
Protocol
Broadband
Forum
2011
[2] tr-157-1-6.xml Component Objects for CWMP,
Amendment 6
Broadband
Forum
2012
[3] TMF8002-IPDR-IIS-DG IPDR Service Specification
Design Guide, Version 3.8,
Release 1.0
TM
Forum
2009
[4] TMF8001-IPDR-IIS-PS IPDR/XDR Encoding Format, V3.8
– Release 1.0
TM
Forum
2009
[5] TMF877-IPDR-IIS-PS IPDR/XML File Encoding Format,
V3.7 – Release 1.0
TM
Forum
2009
[6] TMF8000-IPDR-IIS-PS IPDR Streaming Protocol
(IPDR/SP), V2.7
TM
Forum
2011
[7] TMF878-IPDR-IIS-PS IPDR/File Transfer Protocol, V3.9
– Release 1.0
TM
Forum
2009
[8] RFC 2119 Key words for use in RFCs to
Indicate Requirement Levels
IETF 1997
2.3 Definitions
The following terminology is used throughout this Technical Report.
ACS A software component in the broadband network responsible for auto-configuration
of the CPE for advanced services. This software component utilizes CWMP, as
defined in TR-069 [1], to communicate to the CPE in the broadband network.
Data Encoding Specifies a set of rules that defines how information is turned into a format such that
it can be transported across the network via the protocol.
Data Format Specifies a set of rules that defines how the information is organized.
IPDR Collector A software component in the broadband network responsible for collecting IPDR
Documents from the IPDR Exporter.

IPDR Document A series of records that were generated for transmission across an IPDR Session or
during a specific collection interval.
IPDR Exporter A software component in the broadband network responsible for exporting IPDR
Documents to the IPDR Collector. For the purpose of this document the IPDR
Exporter is the CPE.
IPDR Group An IPDR File Transfer Protocol concept that associates multiple IPDR Documents.
For the purposes of this document an IPDR Group directly corresponds to an
instance of the BulkData.Profile table (see A.5 for more details).
IPDR Session An IPDR Streaming Protocol concept that defines a set of different data templates
for different applications and enables the collection of IPDR Documents. For the
purposes of this document an IPDR Session directly corresponds to an instance of
the BulkData.Profile table (see A.5 for more details).
Protocol Specifies a set of rules that controls how information is transported across the
network.
2.4 Abbreviations
This Technical Report uses the following abbreviations:
BSS Business Support System
CPE Customer Premise Equipment
CWMP CPE WAN Management Protocol
IP Internet Protocol
IPDR IP Detail Record
IPDRDoc IPDR Document
IR IPDR Recorder
IS IPDR Store
IT IPDR Transmitter
OUI Organizationally Unique Identifier
SE Service Element
TR Technical Report
WAN Wide Area Network
WG Working Group

3 Technical Report Impact
3.1 Energy Efficiency
TR-232 has no impact on Energy Efficiency.
3.2 IPv6
TR-232 has no impact on IPv6.
3.3 Security
TR-232 has no direct impact on Security. Any Security concerns over using or implementing
this solution are part of the underlying IPDR protocol and are fully explained in the TM Forum
documentation regarding IPDR.
3.4 Privacy
TR-232 has no direct impact on user data Privacy. Any Privacy concerns over using or
implementing this solution are part of the underlying data models that are implemented on the
devices, meaning that this mechanism does not override any data model constraints on sensitive
user data.

4 Bulk Data Collection Service Specification
This is the format to be used when publishing this Technical Report as an IPDR Service
Specification (see the IPDR Service Specification Design Guide [3] for more details about the
structure).
4.1 Title Page
When the IPDR Service Specification is created, the “Title Page” will be the same style as the
IPDR Service Specification Design Guide, but it will contain the information that is located on the
Title Page of this Technical Report.
4.2 Preface
4.2.1 Contacts
When the IPDR Service Specification is created, this section will contain the contents of the table
that documents the Editors of this Technical Report and the Broadband Home WG Chairs, which
in this Technical Report is located between the Revision History table and the Table of Contents.
4.2.2 Acknowledgements
When the IPDR Service Specification is created, this section will contain a list of companies that
contributed to the creation of this Technical Report, which can be created by searching through
the Broadband Forum contribution site.
4.2.3 Abstract
When the IPDR Service Specification is created, this section will contain the Executive Summary
from this Technical Report.
4.2.4 Change History
When the IPDR Service Specification is created, this section will contain the Revision History
table from this Technical Report.
4.2.5 Table of Contents
When the IPDR Service Specification is created, this section will contain the Table of Contents for
the IPDR Service Specification, which is auto-generated by Word.

4.3 Introduction
4.3.1 Purpose
The purpose of TR-232 is to define an IPDR Service Specification in line with the Service
Specification Design Guide [3].
An IPDR Service Specification defines a service’s usage of IPDR including all pertinent use
cases, all definitions for data to traverse between the two entities, and a detailed XML Schema
that governs the data sent via the service.
4.3.2 Compatibility
Future revisions are expected to make every attempt to preserve investments made by service
providers and solution vendors by considering backward and forward compatibility whenever it
is practical.
4.3.3 References
The following references constitute provisions of this Technical Report. At the time of
publication, the editions indicated were valid. All references are subject to revision; users of this
document are therefore encouraged to investigate the possibility of applying the most recent
edition of the references listed below.
When the IPDR Service Specification is created, this part of the section will contain a list of
reference for all external documents mentioned within the IPDR Service Specification, which will
be a subset of Section 2.2 from this Technical Report.
TMF8001-IPDR-IIS-PS IPDR/XDR Encoding Format, V3.8 – Release 1.0 TM Forum 2009
TMF877-IPDR-IIS-PS
IPDR/XML File Encoding Format, V3.7 – Release
1.0
TM Forum 2009
TMF8000-IPDR-IIS-PS IPDR Streaming Protocol (IPDR/SP), V2.7 TM Forum 2011
TMF878-IPDR-IIS-PS IPDR/File Transfer Protocol, V3.9 – Release 1.0 TM Forum 2009

4.3.4 Overview
TR-232 defines a complete IPDR Service Specification [3] detailing the collection of bulk data
for CPE. This document also defines a data model for use in CWMP (as defined in TR-069 [1])
managed devices to configure the IPDR mechanism being used to collect and deliver the bulk
data.
TR-232 is separated into 3 sections:
Bulk Data Collection Use Case – including the CWMP mechanism for configuring the
collection of bulk data.
Data Definitions – describing the attributes essential for the reporting of bulk data.
Service Definitions – detailing the XML Schema and sample instance documents.

4.4 Use Case
Service Providers are increasingly interested in retrieving large quantities of data from their
installed CPE base at regular intervals. The amount of data being requested represents a
significant portion of the CPE’s data model and is thus a large amount of data. This IPDR-based
service specification defines a mechanism for collecting and transmitting this data out-of-band
from a CWMP management session thereby saving network resources and ACS resources.
4.4.1 Basic Use Case
Figure 1 – Operational View of Bulk Data Collection

The use case depicted above is outlined here:
1. The ACS discovers the Bulk Data Collection capabilities of the CPE in question
a. Retrieve the Minimum Reporting Interval
b. Retrieve the Supported Protocols
c. Retrieve the Supported Encoding Types
d. Retrieve the Maximum Number of Profiles supported
e. Retrieve the Maximum Number of Parameters that can be Referenced
2. The ACS creates and configures a collection profile
a. Enable the general Bulk Data Collection mechanism
b. Create a Profile instance
c. Set the Alias for this collection profile (the Alias will also be either the name of
the IPDR Session, if using the IPDR Streaming Protocol, or the name of the IPDR
Group, if using the IPDR File Transfer Protocol)
d. Set the Reporting Interval for this collection profile
e. Set the Time Reference (time of day) for this collection profile
f. Set the Protocol to be used for this collection profile
g. Set the Encoding Type to be used for this collection profile
h. Set either the IPDR Streaming Protocol specific parameters (StreamingHost,
StreamingPort, StreamingSessionID) OR the IPDR File Transfer Protocol specific
parameters (FileTransferURL, FileTransferUsername, FileTransferPassword,
ControlFileFormat) for this collection profile
3. The ACS configures the individual parameters or parameter paths to be collected
4. Enable the collection profile that was created in Step 2 and fully configured across Steps
2 and 3
5. Depending on how the CPE was configured in Step 2 above, the CPE will either use the
IPDR Streaming Protocol to deliver information to the IPDR Collector as the time
interval dictates OR use the IPDR File Transfer Protocol and wait for the IPDR Collector
to gather the IPDR Document(s) that have been created based on the configured time
interval.
4.4.2 CWMP Data Model
In order to allow an ACS to remotely configure the IPDR mechanism, a data model component
is defined in tr-157-1-6.xml [2]. The data model allows the ACS to configure protocol details,
reporting intervals, collection URLs, credentials, and the set of data to be collected. The data
model component was first included in the following root data models: Device:1.10, Device:2.5,
and InternetGatewayDevice:1.11.

4.5 Data Definitions
4.5.1 BulkDataReport
There SHOULD be only one BulkDataReport record per each IPDRDoc.
4.5.1.1 OUI
The Organizationally Unique Identifier (OUI) of the device manufacturer. The OUI is
represented as a six hexadecimal-digit value using all upper-case letters and including any
leading zeros.
This value MUST be a valid OUI as defined in Organizationally Unique Identifiers (OUIs)
http://standards.ieee.org/faqs/OUI.html.
4.5.1.2 ProductClass
This is the identifier of the class of product for which the serial number applies. That is, for a
given manufacturer, this parameter is used to identify the product or class of product over which
the SerialNumber is unique.
4.5.1.3 SerialNumber
This is the identifier of the particular device that is unique for the indicated class of product and
OUI.
4.5.1.4 Suspect
This is a boolean identifying the data integrity status of the bulk data being collected by this
device. A false value means that there is no problem with this report and that the data is
complete. A true value means that there is a problem with this report and that the data contained
in this report is not complete.

4.5.1.5 BulkData
Each Bulk Data item will correspond to a single piece of information that was requested for
collection.
4.5.1.5.1 Name
This is the fully qualified name of a CWMP parameter that is being collected as bulk data. The
parameter name MUST adhere to the requirements specified in Section 3.6.1/TR-069a4 [1]
regarding instance identifiers and the value of the InstanceMode parameter.
4.5.1.5.2 Value
This is the value, in string format, of the CWMP parameter that is being collected as bulk data.
Only printable ASCII characters can be present in the transmitted data (i.e. characters whose hex
ASCII representations are in the inclusive range of hex 20 to 7E) and any non-ASCII characters
or non-printable ASCII characters that exist in the original data MUST be converted to the ‘.’
(hex 2E) character before transmission.

4.5.2 Formal Definitions
Table 1 – IPDR Formal Data Definition
Category Name Type Presence Permitted Values Remarks
BulkDataReport
Who OUI String Required
Six hexadecimal-digit value
using all upper-case letters
and including any leading
zeros
See
Section
4.5.1.1
Who ProductClass String Required
See
Section
4.5.1.2
Who SerialNumber String Required
See
Section
4.5.1.3
What Suspect Boolean Required
See
Section
4.5.1.4
What BulkData.Name String Required
See
Section
4.5.1.5.1
What BulkData.Value String Required
See
Section
4.5.1.5.2

4.6 Service Definition
4.6.1 XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<!--
IPDR Service Specification for Bulk Data Collection
Notice:
The Broadband Forum is a non-profit corporation organized to create
guidelines for broadband network system development and deployment.
This Broadband Forum Document has been approved by members of the
Forum. This Broadband Forum Document is not binding on the Broadband
Forum, any of its members, or any developer or service provider.
This Broadband Forum Document is subject to change, but only with
approval of members of the Forum. This Document is copyrighted by
the Broadband Forum, and all rights are reserved. Portions of this
Document may be copyrighted by Broadband Forum members.
This Broadband Forum Document is provided AS IS, WITH ALL FAULTS.
ANY PERSON HOLDING A COPYRIGHT IN THIS BROADBAND FORUM DOCUMENT,
OR ANY PORTION THEREOF, DISCLAIMS TO THE FULLEST EXTENT PERMITTED
BY LAW ANY REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY:
(a) OF ACCURACY, COMPLETENESS, MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE;
(b) THAT THE CONTENTS OF THIS BROADBAND FORUM DOCUMENT ARE SUITABLE
FOR ANY PURPOSE, EVEN IF THAT PURPOSE IS KNOWN TO THE COPYRIGHT
HOLDER;
(c) THAT THE IMPLEMENTATION OF THE CONTENTS OF THE DOCUMENT WILL NOT
INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR
OTHER RIGHTS.
By using this Broadband Forum Document, users acknowledge that
implementation may require licenses to patents. The Broadband Forum
encourages but does not require its members to identify such
patents. For a list of declarations made by Broadband Forum member
companies, please see http://www.broadband-forum.org. No assurance
is given that licenses to patents necessary to implement this
Document will be available for license at all or on reasonable and
non-discriminatory terms.
ANY PERSON HOLDING A COPYRIGHT IN THIS BROADBAND FORUM DOCUMENT, OR
ANY PORTION THEREOF, DISCLAIMS TO THE FULLEST EXTENT PERMITTED BY
LAW (A) ANY LIABILITY (INCLUDING DIRECT, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES UNDER ANY LEGAL THEORY) ARISING FROM OR
RELATED TO THE USE OF OR RELIANCE UPON THIS DOCUMENT; AND (B) ANY
OBLIGATION TO UPDATE OR CORRECT THIS DOCUMENT.
Broadband Forum Documents may be copied, downloaded, stored on a

server or otherwise re-distributed in their entirety only, and may
not be modified without the advance written permission of the
Broadband Forum.
The text of this notice must be included in all copies of this
Broadband Forum Document.
Summary:
This document defines the IPDR Service Definition for the Bulk Data
Service Specification.
Version History:
* May 2012: Initial Version
-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ipdr="http://www.ipdr.org/namespaces/ipdr"
xmlns:bdc="urn:broadband-forum-org:ipdr:tr-232-1-0"
targetNamespace="urn:broadband-forum-org:ipdr:tr-232-1-0"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="http://www.ipdr.org/public/IPDRTypes.xsd"/>
<xs:import namespace="http://www.ipdr.org/namespaces/ipdr"
schemaLocation="http://www.ipdr.org/public/IPDRDoc3.5.1.xsd"/>
<xs:element name="OUI" type="xs:string">
<xs:annotation>
<xs:appinfo>
The value MUST be a valid OUI as defined in:
Organizationally Unique Identifiers (OUIs)
http://standards.ieee.org/faqs/OUI.html
</xs:appinfo>
<xs:documentation>
Organizationally unique identifier of the device manufacturer.
Represented as a six hexadecimal-digit value using all
upper-case letters and including any leading zeros.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ProductClass" type="xs:string">
<xs:annotation>
<xs:documentation>
Identifier of the class of product for which the serial number
applies. That is, for a given manufacturer, this parameter is
used to identify the product or class of product over which
the SerialNumber parameter is unique.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="SerialNumber" type="xs:string">
<xs:annotation>
<xs:documentation>
Identifier of the particular device that is unique for the
indicated class of product and manufacturer.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="Suspect" type="xs:boolean">
<xs:annotation>

<xs:documentation>
The data integrity status of the bulk data being collected by
this device. A false value means that there is no problem
with this report and that the data is complete. A true value
means that there is a problem with this report and that the
data contained in this report is not complete.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="Name" type="xs:string">
<xs:annotation>
<xs:documentation>
The fully qualified name of a CWMP parameter that is being
collected as bulk data. The parameter name MUST adhere to the
requirements specified in Section 3.6.1/TR-069a4 regarding
instance identifiers and the value of the InstanceMode
parameter.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="Value" type="xs:string">
<xs:annotation>
<xs:documentation>
The value, in string format, of the CWMP parameter defined
that is being collected as bulk data. Only printable ASCII
characters can be present in the transmitted data (i.e.
characters whose hex ASCII representation are in the
inclusive range of hex 20 to 7E) and any non-ASCII
characters or non-printable ASCII characters that exist in
the original data MUST be converted to the ‘.’ (hex 2E)
character before transmission.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="BulkData">
<xs:complexType>
<xs:sequence>
<xs:element ref="bdc:Name"/>
<xs:element ref="bdc:Value"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="BulkDataReport">
<xs:complexContent>
<xs:extension base="ipdr:IPDRType">
<xs:sequence>
<xs:element ref="bdc:OUI" minOccurs="1"/>
<xs:element ref="bdc:ProductClass" minOccurs="1"/>
<xs:element ref="bdc:SerialNumber" minOccurs="1"/>
<xs:element ref="bdc:Suspect" minOccurs="1"/>
<xs:element ref="bdc:BulkData" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>

4.6.2 Sample Instance Document
<?xml version="1.0" encoding="UTF-8"?>
<ipdr:IPDRDoc xmlns:ipdr="http://www.ipdr.org/namespaces/ipdr"
xmlns="urn:broadband-forum-org:ipdr:tr-232-1-0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:broadband-forum-org:ipdr:tr-232-1-0
tr-232-1-0-0-serviceSpec.xsd
http://www.ipdr.org/namespaces/ipdr
http://www.ipdr.org/public/IPDRDoc3.5.1.xsd"
docId="f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
creationTime="2008-08-27T10:04:03Z"
IPDRRecorderInfo="ExampleProfile"
version="3.5.1">
<ipdr:IPDR xsi:type="BulkDataReport">
<OUI>00D09E</OUI>
<ProductClass></ProductClass>
<SerialNumber>71234813214</SerialNumber>
<Suspect>false</Suspect>
<BulkData>
<Name>InternetGatewayDevice.DeviceInfo.UpTime</Name>
<Value>771234</Value>
</BulkData>
<BulkData>
<Name>InternetGatewayDevice.Time.NTPServer1</Name>
<Value>time.gov</Value>
</BulkData>
<BulkData>
<Name>InternetGatewayDevice.Time.NTPServer2</Name>
<Value>time.xyzcorp.com</Value>
</BulkData>
<BulkData>
<Name>InternetGatewayDevice.Time.CurrentLocalTime</Name>
<Value>2008-08-27T10:04:04Z</Value>
</BulkData>
</ipdr:IPDR>
<ipdr:IPDRDoc.End count="1" endTime="2008-08-27T10:04:05Z"/>
</ipdr:IPDRDoc>

Annex A: IPDR Theory of Operation
A.1 Introduction
The IPDR reference architecture is presented in Figure 2, which depicts a Service Element
communicating to an IPDR Recorder that sends messages to the IPDR Transmitter and
optionally to an IPDR Store. The IPDR Transmitter is responsible for sending messages to the
BSS (a.k.a. Business Management System in the reference diagram). For the purposes of this
implementation, the “E” and “F” interfaces supporting multi-party settlement are ignored.
Figure 2 – IPDR Reference Architecture
From the perspective of the Broadband Forum and this Technical Report, the CPE is the Service
Element and IPDR Exporter, and the IPDR Collector is the BSS. The IPDR documentation
clarifies that the following scenario, where the Service Element directly communicates to the
BSS, is valid and simply means that the IPDR Recorder and IPDR Transmitter (collectively the
IPDR Exporter in this use case) are all incorporated into the Service Element. The Service
Element is permitted to directly interface with the BSS if it supports the “D” interface
specifications including backing stores and retransmission of IPDR documents.
Figure 3 – Simplified IPDR Architecture

A.2 IPDR Nodes
Service Elements (SE) : The equipment and software that collects data and delivers it to an
IPDR Recorder. For our purposes, this is the CPE.
IPDR Recorder (IR) : An entity that collects information from the SE and generates IPDR data
from that information. For our purposes, this entity is contained within the CPE.
IPDR Store (IS) : An optional entity that persists IPDR data sent from an IR and delivers it as
needed to an IT. For our purposes, this optional entity is not required.
IPDR Transmitter (IT) : An entity that builds, organizes, and then delivers IPDR documents to
a BSS. For our purposes, this entity is contained within the CPE.
Business Support System (BSS) : An entity that collects IPDR documents and utilizes them in
some fashion. For our purposes, this entity is the IPDR Collector that either retrieves the IPDR
documents or has the IPDR documents pushed to it.
A.3 IPDR Interfaces
The IPDR Reference Model identifies 6 interfaces and includes definitions for 4 of them:
Interface Description
A
Vendor proprietary. High-volume with high granularity void of context. This interface is
not part of the IPDR Protocol.
B IPDR Data Interface. From IPDR Recorders to IPDR Stores or IPDR Transmitters.
C IPDR Store Export Interface.
D BSS Interface. XML or XDR data from IPDR Exporter to IPDR Collector
E Settlement Interface. Connects Service Delivery Business Management Systems.
F Financial System Interface. This interface is not part of the IPDR Protocol.
Table 2 – IPDR Interfaces
From the perspective of the Broadband Forum and this Technical Report, the D interface is the
only one we are interested in as the SE contains the IR and IT (meaning that the A and B
interfaces are all internal to the CPE). The D interface is described in the IPDR File Transfer
Protocol document [7] and the IPDR Streaming Protocol document [6] (i.e. the two protocols
that we talk about in the TR-157 BulkData component). The IPDR File Transfer Protocol [7]
uses FTP or HTTP to transfer files that contain IPDR records from the SE to the BSS. The IPDR
Streaming Protocol [6] uses SCTP or TCP to transfer IPDR records from the SE to the BSS

using highly efficient XDR encoding as described in the IPDR/XDR Encoding Format document
[4] or an XML encoding as described in the IPDR/XML File Encoding Format document [5].
A.4 Recommended Data Collection Techniques
The recommended IPDR data collection techniques for the D interface (i.e. between the IT and
the BSS, or in our case between the CPE and the IPDR Collector) are as follows:
1. IPDR Transmitter Push (IT Push) : The IPDR Transmitter (or CPE in our case) delivers
the IPDR records to a known BSS. This is done via the IPDR Streaming Protocol [6].
This method includes options for different session types, which permit time-based
exports, event-based exports, event-based exports with time constraints, or exports in
response to a request from the collector (ad-hoc exports). These types can be mixed and
matched to accommodate different export requirements based upon the type of data being
exported, but only the time-based exports (Time Interval Session Type) are currently
supported.
2. Business Support System Pull (BSS Pull) : The BSS logically subscribes to specific
IPDRDocs from the IPDR Transmitter (or CPE in our case). This is done via the IPDR
File Transfer Protocol [7].
A.5 Implementation Guidelines
A.5.1 IPDR Recorder Information
The IPDR Document has a field in the IPDR element named “IPDRRecorderInfo”, which is
intended to contain identification information for the producer of the document. Since the Bulk
Data Report already contains the typical CPE identification information (OUI, Product Class,
and Serial Number), this field will be populated with the value of the Alias parameter within the
Profile object (BulkData.Profile.{i}.Alias). The Alias parameter is a non-functional unique key
for the Profile table and will typically be ACS driven, so this provides a means for the IPDR
Collector to correlate the IPDR Document to a specific Bulk Data Profile.
A.5.2 IPDR Streaming Protocol Considerations
When a device has bulk data collection enabled it will be configured to have one or more
collection profiles (BulkData.Profile.{i}). If the collection profile is configured to use the IPDR
Streaming Protocol [6], then the collection profile directly maps to the Session concept defined
within the IPDR Streaming Protocol.
The IPDR Exporter (the CPE in our case) always initiates the connection as we are only dealing
with time-based exports. This document also limits the transport protocol being used to only
TCP, instead of SCTP or BEEP, which should limit the number of transport protocols that need
to be supported by the CPE. An IPDR Collector can request all available sessions from the

IPDR Exporter where the response is a list of sessions including the session identifier (which is
used to start collecting data), the session name (which is the value of the Alias parameter within
the BulkData.Profile.{i} table), and the session type (which is always “Time Interval Session”).
After the IPDR Collector determines the session it wants to receive information for, the IPDR
Collector then informs the IPDR Exporter to start sending information by sending a “flow start”
message including the appropriate session identifier (BulkData.Profile.{i}.StreamingSessionID).
When the IPDR Exporter receives the “flow start” message it then begins a data template
negotiation phase, which in our case will be the IPDR Exporter sending the template that
matches data definition defined within Section 4.5 followed by the IPDR Collector
acknowledging the template without any changes. At this point in time the IPDR Exporter sends
a “session start” message and then begins to issue the IPDR Data message(s), which contain the
BulkData IPDR Document. Each IPDR Data message will need an acknowledgement from the
IPDR Collector when it has been successfully received. After the BulkData IPDR Document is
transmitted and received then either the IPDR Exporter or the IPDR Collector is free to terminate
the communications session. See the following figure for a graphical representation of this
overview.
Figure 4 – IPDR Streaming Protocol Interaction Flow

Either the IPDR Exporter or the IPDR Collector can terminate the IPDR Session and thus the
TCP connection that the IPDR Session is riding across. The IPDR Exporter terminates the
session by issuing the IPDR Session Stop message, which tells the IPDR Collector that it has no
further information to send. Whether or not the IPDR Exporter issues this message immediately
after the BulkData record has been sent or not is currently implementation specific, but a
guideline is to base this decision on the frequency of the collection profile’s reporting interval.
For example, if the reporting interval is 15 minutes, then perhaps it should hold the session open,
but if the reporting interval is 24 hours then it should probably close the session after sending the
BulkData record. The IPDR Collector terminates the session by issuing the IPDR Flow Stop
message, which tells the IPDR Exporter that it does not want to receive any more information
within this session. This is typically driven by a lack of resources within the IPDR Collector.
Whether the session is terminated or not, the collection profile’s reporting interval and time
reference drives when the next BulkData IPDR Document is delivered from the IPDR Exporter.
A.5.3 IPDR File Transfer Protocol Considerations
When a device has bulk data collection enabled it will be configured to have one or more
collection profiles (BulkData.Profile.{i}). If the collection profile is configured to use the IPDR
File Transfer Protocol [7], then the collection profile directly maps to the Group concept defined
within the IPDR File Transfer Protocol.
End of Broadband Forum Technical Report TR-232

TR-232 (Bulk Data Collection).pdf

More Related Content

Recently uploaded (20)

Featured (20)

TR-232 (Bulk Data Collection).pdf