PMP Technical Description

PMP
Pirelli Management Platform
PIRELLI MANAGEMENT
PLATFORM 6.1
TECHNICAL DESCRIPTION
PMP
Pirelli Management Platform
This document contains Pirelli proprietary and confidential information. No part of this document may be copied, reprinted or
reproduced in any material form or electronically, whether wholly or in part, and no information contained herein may be used or
disclosed to third parties unless under a previous written agreement with Pirelli Broadband Solutions setting forth relevant terms and
conditions.
PMP Technical Description
Pirelli Management Platform Confidential
SUMMARY
1 INTRODUCTION.................................................................................. 3
2 DEFINITIONS.....................................................................................3
3 REFERENCES......................................................................................3
4 SYSTEM OVERVIEW............................................................................4
4.1 Introduction.....................................................................................................4
4.2 Product key Benefits.........................................................................................4
5 USES CASES.......................................................................................9
5.1 Automatic first installation.................................................................................9
5.2 Update campaign............................................................................................10
5.3 Helpdesk call with remote access to CPE ...........................................................12
5.4 VoIp service activation ....................................................................................14
6 NETWORK ARCHITECTURE...............................................................16
6.1 Network Applications.......................................................................................16
6.2 Deployment Scenarios.....................................................................................18
6.2.1 Single Server Scenario .........................................................................18
6.2.2 Clustered Scenario................................................................................19
6.2.3 Distributed Scenario.............................................................................20
6.3 System Logical Breakdown...............................................................................21
7 UNITS FUNCTIONAL DESCRIPTION..................................................25

7.1 Activities Policy Management............................................................................25
7.2 Provisioning....................................................................................................26
7.2.1 Service Auto Configuration....................................................................28
7.3 Assurance......................................................................................................32
7.3.1 Diagnostics..........................................................................................33
7.4 Download.......................................................................................................36
7.5 Performance Monitoring...................................................................................36
7.6 Events Management........................................................................................38
7.7 Groups Management.......................................................................................43
7.8 PMP Integration Of New Device Types................................................................44
7.9 PMP Integration To Service Management Systems...............................................46
7.9.1 OSS Adapter Module.............................................................................47
7.9.2 Northbound Interface methods...............................................................47
Rev. A1
1
Rev. A1
2
1 INTRODUCTION
Scope of this document is to provide a technical description of the PMP ACS solution proposal.
2 DEFINITIONS
AAA Authorization, Authentication and Accounting system
ACS Auto-Configuration System
CPE Customer Premises Equipment
CWMP CPE WAN Management Protocol
DB Data Base
DMP Dual Mode Phone
ESB Enterprise Service Bus
HGI Home Gateway Initiative (http://www.homegatewayinitiative.org/)
MIB Management Information Base
JMS Java Messaging Service
OMA Open Mobile Alliance
OSS Operations Support Systems
SCP Service Control Platform
SNMP Simple Network Management Protocol
STB Set Top Box
3 REFERENCES
[1] CPE WAN Management Protocol, DSL Forum, Technical Report, TR-069
Rev. A1
3
4 SYSTEM OVERVIEW
4.1 Introduction
The Pirelli Management Platform (PMP) is a pioneer application of Home Network Remote
Management for value added broadband services.
Developed in compliance to DSLForum and HGI standards it is created to respond to the main
challenge in the implementation of next-generation multiple-play service strategies. It satisfies
the need to manage the complexity of:
• fast-growing customer bases

Broadband Provider common scenario requires a management system able to support
high customer subscription rates
• multi-vendor devices (CPEs, set-top boxes, dual mode phones)

In order to be competitive towards device suppliers, service providers require not only
multiple types of devices, but also support for more than one independent hardware
vendor for the same type of devices.
• different management protocols

Different device categories comply with different standard specifications
– CWMP protocol defined by DSLForum TR-069, a new generation remote

management suited standard for access gateways, set top boxes, devices, etc.
– OTAP protocol defined by OMA, a common choice for mobile phones
– secured and plain TELNET protocol, required for custom management operations
• diverse service models

A common requirement by service providers is customer service profiling. When a new
customer will present to management system it will be remotely handled according to
chosen service model
• varied and custom OSS architectures

Integration to service provider infrastructure is provided by an open API available like
web service, command line, or other open interfaces.
• reducing customer care costs and increasing customer satisfaction.
4.2 Product key Benefits
By design, PMP is conceived as a “platform”, i.e. as a framework that can be expanded to

support, in addition to the core ACS functions, additional functional applications, interfaces,
adapters, over a common integration bus.
This makes the PMP unique as a future-proof platform to integrate a successful OSS
architecture in support of the fast evolving broadband services and technologies.
Rev. A1
4
The PMP’s distinctive value proposition for the Telco is to allow:
• easy adaptation
No constraint are introduced to service provider infrastructure. An open interface to OSS
system allows interaction between management server and other enterprise applications.
Adoption is as fast as adding a SOAP interaction or a command line invocation according
to open proved APIs.
• fast deployment
Startup installation times are comparable to the installation of a standard web server like
Apache Tomcat and JBoss Application server on a single machine.
A set of parameters are prompted interactively to installation operator and so installation
times can be estimated in order of hours.
High performance and availability installation is also supported. Please refer to
Deployment Scenarios paragraph for more details.
• easy evolution and maintainability

Adoption of open standard infrastructure, based on J2EE, an JMS-based bus and SOAP
interface, a set of well-known standard technologies, allows plugging of additional
components and near real-time deployment of updated versions. Thus, High Service
Availability feature is achieved by design taking into account specific devices, OSS
environment, service workflows and IT infrastructure of the Telco.
One or more
Operation Support Systems (OSS)
Adapter 1 Adapter 2
SOAP
SOAP
SOAP
North Bound Interface

(NBI)
GUI access
Auto Configuration Server

(ACS)
South Bound Interface
(SBI)
TELNET
CWMP
OTAP
...
CPEs, STBs, DMPs
Figure 4-1: PMP interface to external environment
Rev. A1
5
PMP makes this possible by its unique modular architecture, which allows (please refer to
figure 4-1):
• to create southbound protocol adapters to support different types of devices (adding a

component on the bottom side of figure)
• to create northbound adapters to support specific OSS (adding a component on the top
interface of figure).
• to easily adapt workflows to specific logics needs. For example in the interaction with the
northbound OSSs (adding a business process component inside ACS block in figure)
• to exploit the modularity of the business logic Plug-ins and of the Web Application
(adding a business logic component inside ACS block in figure).
• to extend to the Telco’s staff the ability to customize the data models, MIBs, variable
aggregations, catalogue features through an intuitive tool such as the PMP Configurator
(as shown later in this paragraph)
The adoption of PMP brings to the Telco the added value of reduced risk from integration and
customization with the confidence to rely on a platform that can be deployed on both open
source J2EE middleware and, alternatively, best-in-class Enterprise Service Bus (ESB)
architecture, ensuring future-proof maintainability.
Unlike traditional hub-and-spoke integration solutions, which provide inherently limited

scalability, the PMP’s ESB employs a lightweight and flexible bus topology which is not
architecturally constrained.
The PMP is also unique in its ability to address an essential need of remote management
administration: whether by internal IT resources or external software support, the Telco need
to have a flexible tool to manage the logical entities comprised in the application database (the
catalogue) without having to resort to developer’s skills.
Rev. A1
6
The PMP information model is showed in the following picture:
Device Catalogue Device Inventory
Firmware Catalogue Activity management
Service Catalogue Customer Inventory
GUI Catalogue System Configuration
Server Catalogue User Account Config
Figure 4-2: PMP Information Model
The PMP Configurator tool allows Window-Explorer like information model configuration,
such as service profile features, enabling of a new firmware upgrade download, etc. A
screenshot is available below.
Figure 4-3: PMP Configurator
Rev. A1
7
The PMP Configurator satisfies this need with a powerful administration tool integrated in
PMP that offers an easy to use GUI for Catalogue management, allowing to:
• configure the device catalogue
• configure the device Information models
• import SNMP MIBs from ASN.1 files
• import of TR-069 parameters tree from CWMP discovery
• import of OMA parameters tree from XML templates
• configure data models for CPEs
• Create variables aggregations
• Configure discovery profiles
• configure the Service Provisioning Catalogue
• configure the Firmware Catalogue
• configure the GUI Catalogue
• configure the PMP file servers factory
• Save/Load Configuration from File System
• Import/Export Configurations from Database
The availability of a tool like the PMP Configurator has evident economical benefits: it
addresses the customization costs that remain “hidden” in applications where after-purchase
customizations require intensive software specialist developments.
Evaluations carried out with Telcos at advanced stages of remote management deployment,
show that, even in a conservative scenario of moderate service / CPE differentiation, the PMP
Configurator brings significant savings in professional-services cost per year.
Rev. A1
8
5 USES CASES
The following paragraphs describe how PMP performs some typical working scenarios.
5.1 Automatic first installation
Scenario
 A customer comes home with a new gateway. The subscriber proceeds to unpack the
equipment and plugs it into the wall and to the PC. Now he starts looking for installation
manual.
Realization
 PMP configures the equipment automatically so that the user needs not do anything.
The use case is described in Figure 5-4:
Figure 5-4: Automatic first installation use case
Rev. A1
9
Steps details:
1. Set Device/Subscriber association – OSS system issues method

addDeviceSubscriberAssociation() on NBI to bind a given device, identified by
cpeIdentifier, to a subscriber, identified by subscriberId.
2. Device enable store – In this phase, customer/device binding is persisted on internal

database.
3. Set Device/Service association - OSS system issue method

setServiceProfileToDevice() on NBI to bind a given device, identified by cpeIdentifier, to a
service profile, identified by a service name.
4. Service enable store – In this phase, device/service profile binding is persisted on

internal database.
5. First Boot - The customer brings a new device to the promise, connects it to the ADSL
cable and powers on the router. At this moment the device presents itself to the PMP for
the first time.
6. Service Provisioning - service catalogue is queried on PMP internal database and a

provisioning activity is executed on remote CPE. PMP inserts the new CPE into device
inventory with both model information and recovered information
7. Customer care check - Customer care operator accesses the web GUI and asks for a
given device information.
8. Reading of last known configuration – a copy of last known configuration is read

from PMP internal database.
9. Issue get command for remote configuration - PMP contacts the CPE querying for
provisioning parameters.
10. Receiving of current configuration from device - Current CPE data retrieved from
device is sent to GUI.
11. Return configuration to operator – Both last known configuration and current CPE
data retrieved in points 8 and 10 are compared and showed on the web GUI.
5.2 Update campaign
Scenario
 A released firmware contains a bug that would have non-negligible end user impact. The
patched firmware is released as soon as possible and put online for quick upgrading of
the CPE fleet in order to minimize harm to end users. An expert is responsible for
managing the upgrade campaign. The bug can concern only a specific group of CPEs or
all of them.
Rev. A1
10
Realization
 PMP can perform autonomously upgrading either a group of CPEs (specified by operator)
or all of them.
 There are four different cases when a firmware update should be done:
1. Periodical update verifications (CPE polling for an update as it has been

programmed)
2. Patch or update campaign with a specific set of devices targeted
3. Update pushed by a PMP operator because of a client problem
Figure 5-5: Update campaign use case
Steps details:
1. Select group and options by GUI – the operator will select a target group of CPEs for
campaign and its parameters. Destination firmware name is the only mandatory
parameter. It will be selected among those declared available in firmware catalogue for
current device. Start date, end date and daily time window can be also defined. If not
specified, campaign will run immediately, will never end and will be available for all daily
hours.
1bis. Select group and options by NBI – this is an alternative way to start download
campaign. The meaning of parameters is the same as point 1.
2. CPE presence notification – a CPE eligible for update sends a presence notification
Rev. A1
11
3. Check firmware upgrade rules – firmware upgrade rules are checked to proceed to
software upgrade; for example if the CPE is running firmware version v0 and destination
firmware is v10, the download operation will start only if a firmware change of type v0-
>v10 is available on device firmware change catalogue.
4. Issue download command – A download command is sent to CPE to initiate a

download operation. The CPE will start an FTP or HTTP download of firmware image. This
command will be repeated for all CPEs belonging to the chosen group and matching
firmware version change rule.
5. Download command acknowledge – the device replies with a confirmation message

and activity is completed. At this point device will be rebooted if required.
6. GUI campaign report – the operator can monitor software update outcome via e-mails;
he can also check for a campaign progress on the GUI. Checking on CPE information
retrieved from the device he can verify actual device firmware.
5.3 Helpdesk call with remote access to CPE
Scenario
 A customer is experiencing difficulties and calls the hotline. The call is transferred to a
helpdesk agent, who transfers the call to the PMP operator. To understand what is the
problem PMP operator retrieves the CPE information and checks if some parameters are
not as expected.
 We consider customer having a working Internet connection so the remote management

is applicable.
Realization
 The problem is that the customer can’t do external calls with his WiFi terminal.
 The PMP operator can solve these problems visualizing the information and modifying the
CPE configuration.
Rev. A1
12
Figure 5-6: Helpdesk call with remote access to CPE use case
Steps details:
1. Help desk phone call – The customer calls the Help Desk and reports the problem. Help
Desk operator tries to understand the customer problem and decides to verify the
parameters
2. Retrieve CPE Information – On the PMP GUI, the Help Desk operator selects the CPE
using the customer identifiers, and checks the current CPE configuration
3. CPE configuration retrieval – remote CPE is queried in order to retrieve the current
CPE configuration
4. Retrieve stored configuration – The GUI can retrieve from the PMP database the last
known CPE configuration
5. Check configuration mismatch – All CPE parameter values are showed and non
matching values are highlighted in red color.
6. Reconfiguration request – Since there is a problem concerning telephony, the operator

checks the parameters of interest. The operator can decide to apply reconfiguration for
some or all of the parameters.
7. Perform CPE configuration – one or more parameter values are written on the remote
device.
Rev. A1
13
5.4 VoIp service activation
Scenario
 A customer subscribes to the VoIP service. The subscriber already has the gateway up
and running. The customer plugs the telephone to the gateway and it should work
without action from client’s point of view.
Realization
 After receiving a request from the external OSS to activate a new service for a given
subscriber on a given CPE, PMP wakes up the CPE and configures the equipment for the
new functionality.
Figure 5-7: VoIP service activation use case
Steps details:
1. Change service profile on device – an external OSS system issues

setServiceProfileOnDevice() with a VoIP enabled service
2. Send CPE service feature – an external OSS system issues

resynchronizeServiceProfileOnDevice() for the customer/CPE pair by NBI. As service
profile on device is different from OSS configured one, a provisioning activity is
scheduled.
3. Provisioning execution – one or more set operations are issued to execute

provisioning operation.
4. Check provisioning status – concurrently, an operator could check the status of

current provisioning activities, or the result of past provisioning activities.
Rev. A1
14
5. Retrieve stored configuration – The GUI retrieves from the PMP database the last
known CPE configuration.
6. Get CPE configuration - remote CPE is queried in order to retrieve the current CPE
configuration.
7. Check provisioning activity status – Operator can check reporting of successful and
failed provisioning activities. CPE on-board configuration and DB stored configuration are
presented the operator on the GUI, allowing detailed provisioning result check.
Rev. A1
15
6 NETWORK ARCHITECTURE
6.1 Network Applications
The turnkey solution comprises all third party software and middleware required for the PMP
ACS system to run, as described in the following table.
It is to be noted that Oracle and Sun Solaris may be procured directly by the Customers at
their option.
JBoss Message Queue

JBoss Application Server 4.2
Infrastructural Apache Tomcat 5.5

Software
Java SE 5+
Oracle DB 9.2.0.7+ PostgreSQL 8.2+
Operating System
Sun Solaris OS 9+ MS Windows OS
Linux OS
Figure 6-8: PMP base software
Here we give a brief description of typical deploy schemas, leaving out details about the actual
hardware platforms.
The PMP system consists of the following runtime components (see Figure 6-9):
• PMP Web GUI is a J2EE Web Application providing a management console for both
Operators and System Administrators
• PMP North-Bound Interface module offers RPC-based system integration capabilities

both via
– SOAP Web Services (deployed in the J2EE Web Application Server), and
– PMP Admin command line tool
Rev. A1
16
• PMP Database is an RDBMS schema modeling both PMP catalogue data and inventory
data. Database system is accessed via standard JDBC technology. Both Oracle and
PostgreSQL database vendors are supported at present.
• PMP Configurator is a standalone desktop application allowing an administrator user to

configure the PMP database catalogue
• PMP CORE Container running device management services. Different engine modules
enable management for TR-069, OMA and CLI-based devices. This component can be
deployed on JBoss J2EE Application Server or Sonic ESB.
• PMP SOUTH Container running CWMP protocol management services. Different

protocol adapter modules enable management for CWMP, OTAP and Telnet/SSH. This
component can be deployed on JBoss J2EE Application Server or Sonic ESB.
• JMS Broker provides PMP modules with a common communication bus. PMP is
compatible with JBoss MQ and Sonic MQ.
Figure 6-9: PMP Deploy Schema
Leveraging on the product modularity, different deploy solutions can be adopted. The
reference deploy solutions vary by how and by which application runtime components are
distributed on one or more server nodes. An appropriate choice is recommended in order to
address the requirements for:
• High availability
Rev. A1
17
• Scalability
• Security
with the highest cost-effectiveness.
The Reference Production platform is based on SUN servers with SUN StorEdge. Different
hardware classes, with increasing capabilities in term of CPU number, RAM and disk capacity,
can be adopted to vertically scale the same deploy architecture up to the management of
millions of CPEs.
The modular architecture of PMP alternatively allows the possibility of horizontal scalability,
distributing the modules composing the whole application on different servers (please see 6.2
for a description of possible deployment scenarios).
6.2 Deployment Scenarios
The PMP modular architecture allows the possibility to design different deployment scenarios,
thus permitting to scale the application from a solution for the management of few thousands
of devices up to high performance scenarios where the pool of managed devices reaches the
millions of CPEs.
In the following paragraphs different deployment solutions are described.
Note that scenarios reported here are sample configurations. They can be tuned depending
on customer needs.
6.2.1 Single Server Scenario
In this scenario all components belonging to the PMP Platform have been plugged into a single
server inside a Dual Bastion Firewall (DMZ Network). This entry level configuration has been
designed thinking about security and manageability, in fact the only ports needed to be
opened on the firewalls are 8080/tcp (HTTP) to allow access to the Web GUI and more few
ports, depending on the device types to manage, i.e. 8181/tcp (CWMP), between PMP Platform
and Public Network.
The system performances can be scaled in two ways:
• vertically (with more powerful HW)
• moving to a clustered scenario (see section 6.2.2)
Rev. A1
18
Figure 6-10: PMP Single Server Deploy Scenario
6.2.2 Clustered Scenario
In this scenario all components belonging to the PMP Platform have been plugged into an
Application Cluster inside a Dual Bastion Firewall (DMZ Network). The cluster is designed at
PMP application level, and makes use of network load balancing features to manage accesses
from the Public Network, form the OSS Network and from the Operations Network.
Database component, depending on configuration, can be single node or a virtualized multi

node solution in order to achieve high availability and reliability.
The system performances can be scaled in two ways:
• vertically (with more powerful HW)
• moving to a distributed scenario (see section)
Rev. A1
19
Figure 6-11: PMP Clustered Deploy Scenario
6.2.3 Distributed Scenario
In this scenario the components of the PMP Application are distributed:
• central components (the database, messaging brokers, application server for GUI and
SOAP NBI access) have been deployed into an Application Cluster
• device management nodes, hosting the Core and South-bound management layers, can
be replicated in two or more instances to guarantee availability and to scale up
performances (no need to adopt more powerful HW: additional entry level server nodes
could be adopted here to meet growing number of managed CPE)
Figure 6-12: PMP Distributed Deploy Scenario
Rev. A1
20
6.3 System Logical Breakdown
Pirelli Management Platform (PMP) functional architecture is detailed below reported figure.
Figure 6-13: PMP Functional Architecture
PMP functional architecture is composed by:
• PMP Core Layer contains the solution engine that implements device management
business logic. It manages communications with Front-end layer through JMS message
exchange.
• PMP South-bound Layer manages communication tasks between Management Engine and
Devices
PMP Functional components are:
• Protocol Adapters: talk with managed CPE implementing the low level management
protocols (TR-069, GSM, Telnet) both for asynchronous notifications (TR-069 informs)
and for synchronous primitives (TR-069 methods invocations, GSM messages, Telnet
commands). Other functionality performed by adapters are:
– Notification Filtering: the adapter can be configured to ignore and drop specific
notification types in order to reduce message traffic on the bus.
Rev. A1
21
– Message Normalization: All protocol adapters use the same XML schema and
primitives to talk with plugins, independently from the specific management
protocol implemented. In order to accomplish this task a message normalization
and protocol mimics adaptation is required.
Each adapter is specialized in supporting one only management protocol. More instances
of the same protocol adapter can be configured in order to support:
– Load Balancing (for device multiplicity scalability)
– Geographic distribution (along with filtering allows for network traffic

optimization)
– Configuration Management (different revisions of the adapter can be deployed in

order to match stability/features tradeoff required for each device type)
• Device Plugins implement device management logic. Plugins communicate, leveraging

on JMS bus feature, with Protocol Adapters and use a common database instance. Device
plugin core implements management activities workflows.
• Common Services This module provides a layer of common services and software to
support PMP’s core features
• PMP DB The PMP database is an RDBMS schema modeling both catalogue data and
inventory data.
– The catalogue model contains description of supported device types, GUI

configuration, file servers factory configuration and more. The catalogue can be
configured and maintained through the PMP Configurator.
– The inventory model contains live information about managed devices, running
activities, logged activities and more. The inventory is managed automatically by
the system at runtime.
• The PMP Configurator is a standalone desktop application allowing an

administrator user to configure the PMP database catalogue. Two main catalogue
areas are covered:
– Device Types catalogue – to change configuration of existing device types or even

add support for new TR-069, GSM or CLI/Telnet device types
– File Servers catalogue – to edit configuration of the File Servers Factory, supporting
mass firmware upgrade feature
The Configurator manages local XML configuration files and can connect to the PMP
Database, via JDBC, to import and/or export catalogue configuration.
• North-Bound Interface This module provides the implementation of the PMP API
available to external OS systems. The interface protocol is SOAP. All remote procedures
are available also from a command line Admin Tool.
• OSS Adapter This is an optional component, providing the integration between PMP and
the in-field OSS environment. It can be implemented on top of the PMP’s north bound
interface, by means of SOAP methods remote procedure calls. The protocol used at the
OSS side is undefined, depending on the actual systems.
Rev. A1
22
• The AAA OSS component represents a category of OS systems which is likely to need
integration with PMP, to provide additional information and relationship between
customers, devices and service profiles.
• GUI Web Application The Web GUI provides a user interface for the management of
Assurance, Provisioning, Firmware and Administration functionalities. Most of the Web
GUI features operate directly with the PMP Database through JDBC interface. For
interactive activities between the end-user and remote devices, the PMP server-side
components are contacted trough the JMS bus. State of the art Web-based technologies
have been chosen in order to:
– Offer high level of usability for operators and
– Meet the need of customization for system integrators
Figure 6-14: Web GUI Sample: PMP tasks monitoring
Rev. A1
23
Figure 6-15: Web GUI Sample: Subscribed devices management
Rev. A1
24
Figure 6-16: Web GUI Sample: "skinnable" look
7 UNITS FUNCTIONAL DESCRIPTION

PMP provides several operations on CPEs, which are functionally divided into the following
areas:
• Provisioning
• Assurance
• Download
Some of them are performed through an automatic procedure whereas others are typically GUI
activities. Before describing the main operations workflows, the following section introduces
the policy adopted by PMP core engine to carry out management activities.
7.1 Activities Policy Management
PMP Activities are the management tasks carried out by PMP runtime components. PMP
Activities can be issued by:
• Operator users, through the PMP Web GUI
• CPEs, through the PMP south-bound protocol interfaces
• External OS systems, through the PMP north-bound interface
Rev. A1
25
The PMP database allows maintenance of:
• An inventory of PMP activities, where running, queued and logged activities are traced
• A catalogue of the PMP activities, to allow definition and configuration of activities

management policy. Different activity types are defined, and for each type the relevant
policy parameters are:
– Priority
– Timeout
– Maximum concurrent instances
– Scheduling policy (how to start the activity of such type)
– Multiplicity policy (whether to allow multiple queued activities of such type, or not)
– Recovery policy (whether this activity is recoverable after a failure, or not)
– Resume policy (how a recoverable activity can be resumed)
– Automatic Resume Period (when a recoverable activity is resumed by the system)
– Log policy (how to log the final result of an activity)
– Failed policy (how to evaluate the final state of an activity)
– Connection retries (connection attempts to the remote system)
– Communication retries (communication attempts with the remote system)
7.2 Provisioning
Provisioning includes all the operations regarding a service profile configuration on a device.
The provisioning area consists of the following functions:
• Perform a self-activated configuration on a device not yet present in inventory.
• Display the service profiles list and related specific parameters.
• Verify the customer’s profile and reapply it (manual provisioning).
• Monitor the status of provisioning activities (in progress, failed, finished).
• Show all inventory information related to the device.
• Execute a discovery activity on a device.
• Remove the selected device from the PMP database.
• Allow to change the line number associated to the selected device.
Some operations from GUI involve simply a reading activity from catalogue / inventory stored
on PMP’s DB and in general they can be explained by the following scheme:
Rev. A1
26
Figure 7-17: Typical operation which involves a simple reading activity from
catalogue / inventory
Rev. A1
27
Whereas others, more complex functionalities, involve a dialogue between CPE and PMP, as
described in the following figure:
Figure 7-18: Typical operation which implies a dialogue between CPE and PMP
(Manual configuration)
7.2.1 Service Auto Configuration
This paragraph describes in detail the process flow for the automated service instance
provisioning, activation and update.
Auto configuration includes:
• CPE identification phase
• Service provisioning phase
7.2.1.1 CPE Identification Process
The CPE Identification process starts when the device presence is notified to the ACS. After
this triggering event, the following steps are performed:
1. Notification fields are validated for integrity, authorization and completeness. For
example the sender IP address may be compared to WAN IP address declared in
message body. If match fails the request is discarded.
2. Optional information about the geographical area where the device is located can be
discovered. There is support for automatic discovery from subscriber ID and/or IP
address. Moreover, there is support for pluggable custom identification procedures (i.e.
look up in external customer lines database).
3. PMP internal inventory is called to check if device have been already provisioned or not.
4. When CPE is valid and is not present in inventory, additional service information are
required to determine if CPE customer is currently enabled to one or more subscribed
services. This operation usually involves interaction to external Customer Profile
repositories (e.g. CRM OSS). For a stand-alone solution PMP allows the possibility to
Rev. A1
28
insert subscribed devices manually via GUI; obviously this solution is only applicable to
trial installations involved a limited number of managed devices. The available GUI
functions to managed devices are:
a. subscribed devices list browsing
b. subscribed devices list filtering
c. new subscribed device adding
d. existing subscriber’s data modifying
e. existing subscribed devices removing
5. If a customer is enabled to a specific service the corresponding provisioning operation is

performed.
6. When CPE is already in inventory, an additional check is performed to determine if

remote device must be updated to a different service or un-provisioned at all.
Service profile change (step 5) is performed as a special case of provisioning.
CPE presence
notification
CPE valid &

1
authorized ?
Yes
2
CPE in Get Customer 3
No
inventory? Profile Info
Yes
5 4
No Service Update Customer
Required? enabled ? Yes
Yes 6
CPE Provisioning
configuration reset
No
No
End
Figure 7-19: CPE Identification Flow chart
Rev. A1
29
7.2.1.2 CPE Provisioning Process
The Provisioning process is executed only after successful CPE identification
Provisioning consists in services activation. According to PMP naming convention, a Service

Profile is the group of all settings related to a customer subscription.
Aggregation is a set of remote management parameters:
Figure 7-20: Provisioning parameters
Provisioning is completed when all parameter values of all aggregations have been written to
the remote CPE.
The provisioning process can de detailed in the following steps:
1. PMP query its database to choose the service type for the user bound to the given CPE.
2. The first service aggregation is then selected and processed. This step includes retrieving
a list of parameter and values from service catalog database.
3. Some parameters value inside aggregation must be dynamically discovered from external
OSS systems, a common scenario inside service provider network.
4. Next variable to be written is chosen.
5. Current variable is written remotely on CPE. This step involves network traffic. Reference
protocol is CWMP (TR069), but other protocol are supported by PMP via optional
modules.
6. The step 4 and 5 must be repeated for all parameters composing the aggregation.
7. The steps from 2 to 6 must be repeated for all aggregations required to complete the
provisioning
Rev. A1
30
Start
Get User Service

1 Information
Select Next
2
Aggregation
Optionally Query
3 external OSS to
update parameter
values
Select Next
4 Variable
No
5 No Write Variable
6 Last Variable ?
Yes
Last
7 Aggregation
End
Figure 7-21: Provisioning Flow chart
An example of service profile follows: the service FLAT_VOIP_ADSL is composed by 3

aggregations; the first one to enable the VoIP service, the second one to enable the bridged
routing of IP traffic and the third one to disable the IPTV PPPoE session.
Figure 7-22: Service profile
A VoIP aggregation example follows; in the below diagram the tree of parameters to be written
on the CPE is detailed.
Rev. A1
31
Figure 7-23: VoIp aggregation
7.3 Assurance
Assurance refers to reading and writing operations from/to PMP inventory DB and CPE itself.
When supported on CPE side, diagnostic test are also available in this section.
In general this kind of functions involves both the operations on PMP DB and the dialogue
between PMP and the selected devices. The following figure describes an assurance activity:
Figure 7-24: Assurance Use Case
The assurance area includes the following functions:
• Read device information directly from the CPE;
• Read device information from inventory;
• Realign PMP inventory DB according to the information retrieved from CPE;
Rev. A1
32
• Configure attributes selected from GUI into CPE;
• Monitor the status of assurance activities (in progress, failed, finished).
7.3.1 Diagnostics
Some specific assurance features help in the diagnosis of status and issues related to
remote customer devices:
• The Device Summary View (see Figure 7-25): showing device info, live status, alarms,
statistics and line qualification info
• The Line Qualification Report (see Figure 7-26) gives a detailed picture of the quality
of the broadband services for the selected device
• The Diagnostic Test Suite allows: reachability test, standard traceroute, ping (e.g.
Figure 7-27) and others
• The Home Devices Network View (see Figure 7-28), with graphical representation and
info for:
• Devices Managed by PMP
• Other Home Devices connected by LAN, Wireless, USB, etc.
• Voice Lines and/or Terminals
• Connection Status, Alarm Status, Events List
Rev. A1
33
Figure 7-25: Device Summary View
Figure 7-26: Line Qualification Report
Rev. A1
34
Figure 7-27: Ping Diagnostic Test
Rev. A1
35
Figure 7-28: Home Network View
7.4 Download
Download operations refer to the firmware remote update on managed devices.
The PMP download area supports the following functions:
• Perform an automatic download during provisioning (provisioning configuration option);
• Configure from GUI and perform a single download on a selected device;
• Configure from GUI and perform a multiple download on a group of devices;
• Display the status of download activities (in progress, failed, finished);
• Configure of the Hardware/Firmware Catalogue;
• Support file servers factory to balance the load of file transfers via distribution on
different servers
7.5 Performance Monitoring
Rev. A1
36
Performance monitoring operations refer to statistical parameters collection from quality

assurance perspective.
The PMP performance monitoring area supports the following functions:
• periodic data collection for key performance indicators;
• triggering of events for critical values;
• data aggregation and reporting with a top-down approach.
Figure 7-29 is an example of one the available statistical reports that can be visualized in
the GUI. The operator can choose the most significant parameters and visualize them
either on several charts or on the same one.
Figure 7-29: Performance report example
Performance reports GUI pages are available from:
 AssurancePerformancePerformance Statistics – Starts a wizard to report

performance data aggregations related to many CPEs
 AssurancePerformanceXYZ– Report performance data related to a single

CPE. Each menu option bundles together some KPIs, according to user’s definition
coming from PMP Configurator. The option label XYZ is at user’s choice
It is possible to browse data representation filtering by time range.
Different graphics types are available: Lines, Bars, Std Deviation.
Rev. A1
37
It is possible to have a representation of data related to subset of managed CPEs

aggregated by:
 hourly average
 daily average
 weekly average
 monthly average
It is possible to have a representation of data related to subset of managed CPEs

grouping with different criteria:
 by device type
 by firmware version
 by geographical area
7.6 Events Management
PMP manages events coming from:
• managed devices (CPE generated events)
• internal condition triggering (ACS generated events)
Rev. A1
38
Events management features include:
• Database logging and automatic storage size management
• TR069 Informs logging
• TR069 Informs log browsing, filtering and sorting from GUI (see Figure 7-30)
• SMS logging from OMA mobile devices
• SMS log browsing, filtering and sorting from GUI
• Device presence and status update
• Events generation, according to Table 1 below
• Events log browsing, filtering and sorting from GUI (see Figure 7-33)
• Events forwarding to a configurable set of notification recipients. Support for:
 SMTP mail notification
 SNMP trap notification
 Log file append
Event Handler Description Severity
Raised when a factory

reset has been
BOOTSTRAP Inform
performed by user on a Warning
TR069 enabled CPE
Raised when a factory

reset has been
VALUE_CHANGE Inform
performed by user on a Warning
TR069 enabled CPE
Raised when a
monitored CPE kpi
Threshold Exceeded
exceeds the configured
Event Error
threshold, raising an
alarm
Raised when a
monitored CPE kpi gets
Threshold Cleared Event a value within the
Information
configured threshold,
clearing an alarm
Rev. A1
39
Raised when (one of)

PMP Server Start the PMP Server node
Information
starts up
Raised when (one of)

PMP Server Stop the PMP Server node
Information
shuts down
Raised when the PMP

PMP Master Server Start Master Server node
Information
starts up
Raised when the PMP

PMP Master Server Stop Master Server node
Information
shuts down
Table 1 - PMP Events Catalogue
Following figure shows real time report for device events of type Inform.
Figure 7-30: Inform history report
Inform massage tracking is important for TR-069 based Auto Configuration Servers, so
additional statistics graphs are available.
Sample reports about Inform event code distribution are shown below.
Rev. A1
40
Figure 7-31: Event code time graph
Rev. A1
41
Figure 7-32: Event code distribution
Figure 7-33: Events List report
Rev. A1
42
7.7 Groups Management
This is a core product feature added since PMP 3.x major release. By means of Group
Management PMP offers the capability to manage groups of CPEs as target of activities. GUI
operators will be enabled to operate assurance, firmware upgrade, provisioning and inventory
features on CPE group targets, while up to PMP 2.x this was possible on single CPE targets
only.
Device Groups can be defined in two ways:
• From filters set (i.e. device type, category, fw version), or
• Form device list files
Available features to manage devices’ groups are:
• Browsing configured groups
• Adding new Groups
• Removing Groups
The management functions applicable to defined groups are:
• Discovery campaigns: it is possible to configure the execution of a Discovery operation

on all the devices belonging to a specific group and configure the Discovery profile to be
used.
• Backup / Restore campaign: for each device in the target Group, the parameter
values stored in PMP DB can be backup copied, or restored.
• Download campaigns: it is possible to configure the execution of a download operation

on all the devices belonging to a specific group.
• Configuration campaigns: it is possible to configure the execution of parameters

configuration on all the devices belonging to a specific group and type
• Performance Monitoring Campaigns: it is possible to launch periodic monitoring

operations on groups of targets in order to collect data from devices during a certain time
interval. The Monitoring profile, that means the significant variables to be monitored, can
be configured as well as the period of repetition. Thanks to such information,
performance analysis and statistical graphics can be obtained.
Rev. A1
43
7.8 PMP Integration Of New Device Types
The PMP product provides the capability to integrate into management new multi-vendor
device types, leveraging on two characteristics:
• PMP Configurator – this tool can fully support the configuration of the management
profile for new device types, provided that they are compliant to one of the supported
standard protocols:
– CWMP (TR-069)
– OTAP (OMA/GSM)
– Telnet
• Modular architecture – in case of legacy management protocols, PMP is designed to

allow extending the management system with new software modules:
– Protocol adapter modules, deployed in the south-bound layer, can be developed to

cope with legacy management protocols
– Management plugin modules, deployed in the core layer, can be developed to

implement the workflow for the management activities on the legacy device types
In case the new device type supports standard behaviour (i.e. a DSL Forum compliant CPE)
and no specific management functions are required, adding a new configuration profile via PMP
Configurator can be enough to let PMP manage this new device type.
A specific device type is recognized by the system by the following identification parameters:
• The Hardware platform
• The Firmware version
• The mapping between compatible Hardware and Firmware
• The Vendor (or Manufacturer for CWMP devices)
• The Product Class name (only for CWMP devices)
• The OUI code (only for CWMP devices)
Here follow by steps the required integration activities on the PMP Configurator (see Figure 7-
34):
1. Setup the Device Type name, category and class
2. Setup Hardware description
3. Setup Firmware description
4. Setup mapping between Hardware and Firmware
5. Setup Product Class (for CWMP)
Rev. A1
44
6. Setup Parameters Tree - The user can use basic Configurator features to populate the
parameters, following the device vendor’s technical specifications. The Configurator can
help with advanced features like CWMP Discovery, SNMP MIB Import or OMA Parameters
Import.
7. Setup Parameters Aggregations - The information model parameters must be grouped

into Aggregations. Aggregations are the building blocks used by PMP to perform
Assurance and Provisioning features.
8. Setup GUI Configuration – to configure specific dedicated GUI pages for the device type,
and also user profile grants for the management of the device type.
9. Configure Service Provisioning - A device type can support one or more Service Profiles,
each corresponding to specific provisioning sequences. A provisioning sequence can
consist of complex get/set/add/delete operations on the device information model,
depending on the required configuration. The provisioning engine provided by the PMP
system can be instructed from the Configurator tool.
10. Export device type configuration to PMP database catalogue
Figure 7-34: New Standard Device Type Integration
Rev. A1
45
7.9 PMP Integration To Service Management Systems
The PMP product provides a North-Bound Interface in order to integrate the ACS management
features with the hosting Customer’s IT infrastructure.
The North-Bound Interface consists of a set of procedures, remotely callable by a:
• SOAP HTTP Client, or

• Command Line Client
Interfaces towards external systems offer RPC methods enabling:
1. Accounting: set of public APIs to enable authentication and customer identification

management.
2. Provisioning: set of public APIs to manage the provisioning process for each device type.
3. Assurance: set of public APIs to allow set and get commands on managed devices.
4. CPE Groups’ definition: set of public APIs to allow device groups configuration and
management.
5. Download: set of public APIs to manage the firmware download processes.
6. Download Monitoring: set of public APIs to monitor the execution and the results of the
download processes.
Figure 7-35: Information exchanged with OSS
Rev. A1
46
7.9.1 OSS Adapter Module
The common strategy adopted for the in-field integrated deployment is to implement an OSS
Adapter additional module (see Figure 7-36). This module, if needed, can be deployed on the
Sonic ESB runtime framework, thus leveraging on the system integration features offered by
the ESB infrastructure of the PMP system.
Figure 7-36: OSS and PMP Integration strategy
7.9.2 Northbound Interface methods
The Northbound Interface provides the following methods. New functions added since the
latest PMP release are marked with ●.
Authentication and Provisioning Interface
These methods allow management for the associations between the Customer, the Device and
the required Service Profile.
It is also possible to update a Service Profile on a device.
• addDeviceSubscriberAssociation: add into the provisioning repository a new association

between a subscriber with a CPE
• checkDeviceServiceProfileCompatibility: check if the type of the given device is

compatible with a service profile
• deviceInformCLI: update PMP system with information for a device with remote
Command Line Interface
• deviceInformCWMP: update PMP system with information for a TR-069 device
• deviceInformGSM: update PMP system with information for a GSM device
• devicePresence: update PMP system with presence information for a device
• getDeviceServiceProfile: get the service profile associated with a device
Rev. A1
47
• getDeviceServiceProfileStatus: get the current synchronization status of a device against

its service profile
• getDeviceSubscriber: get the subscriber associated to a CPE
• getSubscriberDevices: get the devices associated to a subscriber
• moveDeviceSubscriber: changes the CPE association in the provisioning repository from

the current to a new subscriber identifier
• removeDeviceSubscriberAssociation: remove from the provisioning repository an existing

association between a subscriber with a CPE
• removeProvisioningCampaign: remove a provisioning campaign running on given group
• removeServiceProfileFromDevice: remove the service profile from a device
• resynchronizeServiceProfileOnDevice: queues a provisioning activity for the device
• scheduleProvisioningCampaign: schedule a provisioning activity for the CPE belonging to

the given group
• setServiceProfileToDevice: set the service profile for a device.
• ● getPmpVersion: Returns PMP version string
• ● getDbVersion: Returns PMP DB version string or DB NOT AVAILABLE when DB can't be

contacted
• ● getAllProvisioningActivityStatus: Report of all provisioning activities for the given

device.
• ● getLastProvisioningActivityStatus: Report of last provisioning activity.
• ● getDeviceInfo: Return the list of device type names from device catalogue.
• ● getDeviceTypes: Return information about a device from the inventory.
Group Management Interface
These methods allow device groups definition.
• addGroupCriteria: add a filtering criteria on given group
• createGroup: create a new group with given name
• getGroupMembers: returns the identifier list of devices member of a given group
• getGroupNames: return existing group names list
• removeGroup: remove a group with given name
Rev. A1
48
• removeGroupCriteria: remove a filtering criteria on given group
• setMembersByFile: provide a specific list of devices as group members by loading a text

file
• ● addMembersByFile: add a specific list of devices as group members by loading a text

file
• ● setMembersByIdentifiers: provide a specific list of device identifiers as group members
• ● addMembersByIdentifiers: add a list of device identifiers as group members
• ● removeMembersByIdentifiers: remove a list of device identifiers from group
• ● setMembersByTargets: provide a specific list of target devices as group members
• ● addMembersByTargets: add a list of target devices identifier as group members
• ● removeMembersByTargets: remove a list of target devices identifier from group
Rev. A1
49
Download Interface
These methods allow performing download activities and to monitor the status of the last and
previous downloads.
• getAllDownloadActivityStatus: return the status information for all download activities on

a device
• getDownloadCampaignActivityStatus: return the whole status information for a download

campaign
• getLastDownloadActivityStatus: return the status information for the last download

activity on a device
• removeDownloadCampaign: Remove a download campaign running on given group
• scheduleDownload: schedule a download activity on a given CPE.
• scheduleDownloadCampaign: Schedule download activities for the CPE belonging to the

given group
Assurance Interface
These methods allow OSS to access all configuration parameters for both monitoring and
setting.
• getAggregationNames: retrieve available aggregations for specified CPE
• getDeviceValue: retrieve parameter values from CPE
• getConfiguredValue: retrieve parameter values from PMP database
• getReadValue: retrieve parameter values from PMP database
• setDeviceValue: Set parameter on CPE.
• ● reboot: issue reboot command on specified device
• ● factoryReset: issue factory reset command on specified device
• ● getAllAssuranceActivityStatus: report of all assurance activities for specified CPE
• ● getAssuranceCampaignActivityStatus: report of all assurance activities belonging to the

given group
Event Management Interface

These methods allow device, group and ACS event management.
Rev. A1
50
• ● registerReceiveDeviceGeneratedEvents: OSS registers itself for simple events generated

by a device
• ● unregisterReceiveDeviceGeneratedEvents: OSS unregisters for simple events generated
by a device
• ● registerReceiveACSGeneratedEventsForDevice: OSS registers itself for high-level events
generated by ACS
• ● unregisterReceiveACSGeneratedEventsForDevice: OSS unregisters for high-level events
generated by ACS
• ● listDeviceGeneratedEventNames: returns a list of names of supported Device events
• ● listDeviceGeneratedEventFilters: returns a list of filter names for any Device events,
which can be used in registering for events
• ● listACSGeneratedEventNames: returns a list of names of PMP-generated events (for
generated events related to a given device or not)
• ● listACSGeneratedEventFilters: returns a list of filter names for any PMP-generated
events, which can be used in registering for events
• ● listRegisteredDeviceGeneratedEvents: returns the history of events on a specified device
from a start date to an end date
• ● listRegisteredACSGeneratedEventsForDevice: returns the history of ACS events on
devices from a start date to an end date
• ● listRegisteredReceiveDeviceGeneratedEvents: returns device event names registered on
given URL
• ● listRegisteredReceiveACSGeneratedEventsForDevice: returns ACS event names
registered on given URL
Rev. A1
51

PMP Technical Description

Uploaded by

Copyright:

Available Formats

You might also like

PMP Technical Description

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PMP Technical Description

Uploaded by

Copyright:

Available Formats

PMP

Pirelli Management Platform

7 UNITS FUNCTIONAL DESCRIPTION..................................................25

ACS Auto-Configuration System

CPE Customer Premises Equipment

CWMP CPE WAN Management Protocol

DMP Dual Mode Phone

ESB Enterprise Service Bus

HGI Home Gateway Initiative (http://www.homegatewayinitiative.org/)

MIB Management Information Base

JMS Java Messaging Service

OMA Open Mobile Alliance

OSS Operations Support Systems

SCP Service Control Platform

SNMP Simple Network Management Protocol

STB Set Top Box

• fast-growing customer bases

• multi-vendor devices (CPEs, set-top boxes, dual mode phones)

• different management protocols

– CWMP protocol defined by DSLForum TR-069, a new generation remote

– OTAP protocol defined by OMA, a common choice for mobile phones

• diverse service models

• varied and custom OSS architectures

• reducing customer care costs and increasing customer satisfaction.

4.2 Product key Benefits

By design, PMP is conceived as a “platform”, i.e. as a framework that can be expanded to

The PMP’s distinctive value proposition for the Telco is to allow:

• easy evolution and maintainability

North Bound Interface

Auto Configuration Server

CPEs, STBs, DMPs

Figure 4-1: PMP interface to external environment

• to create southbound protocol adapters to support different types of devices (adding a

Unlike traditional hub-and-spoke integration solutions, which provide inherently limited

The PMP information model is showed in the following picture:

Device Catalogue Device Inventory

Firmware Catalogue Activity management

Service Catalogue Customer Inventory

GUI Catalogue System Configuration

Server Catalogue User Account Config

Figure 4-2: PMP Information Model

Figure 4-3: PMP Configurator

• configure the device catalogue

• configure the device Information models

• import SNMP MIBs from ASN.1 files

• import of TR-069 parameters tree from CWMP discovery

• import of OMA parameters tree from XML templates

• configure data models for CPEs

• Create variables aggregations

• Configure discovery profiles

• configure the Service Provisioning Catalogue

• configure the Firmware Catalogue

• configure the GUI Catalogue

• configure the PMP file servers factory

• Save/Load Configuration from File System

• Import/Export Configurations from Database

5.1 Automatic first installation

The use case is described in Figure 5-4: