mtnl delhi hld_motive 1.0

High Level Design DocumentMTNL Delhi High Speed Data and HDM

Document Version 1.09th July, 2008Motive Consulting Services

2008 Motive, Inc. The Motive logo, Motive, Inc., MotiveSmart, and all other Motive products and technology names are trademarks or registered trademarks of Motive, Inc. All other products or services mentioned herein are trademarks of their respective companies.

Table of contents4Section 1 | Document Overview

4Document Structure

4Revision History

4References

6Section 2 | Project Overview

6Overview

6Scope Definition

7Assumptions

8Section 3 | Design

8Overview

8Hardware Configuration Architecture

9Logical Flow

10Section 4 | Process Communication

10Broadband Subscriber Activation Service

11Self Service Manager Customer Service Manager

12HDM Password Recovery

13Section 5 | Logical Data Design

13Customer Data Model

13MTNL Subscriber Table

15Section 6 | High-level HSD and HDM Use Cases

15High-level MTNL HDM & Activation Use Case

17Section 7 | HDM Use Cases

17Use Case #1 New Subscriber Activation First Run

19Use Case #2 Existing Subscriber Rerun of the Activation CD

21Use Case #3 Activation in Second Computer

22Use Case #4 Factory Reset

24Use Case #5 CPE Swap: CPE1 User2

26Use Case #6 CPE Swap: CPE2 User1

28Use Case #7 Add MTNL User Information

29Use Case #8 Update MTNL User Information

30Use Case #9 Delete MTNL User Information

31Use Case #10 Enable/Disable Service on the CPE

32Use Case #11 MTNL User Password Change

34Section 8 | Reports

37Section 9 | Appendix

37Supported Customer Premise Equipment (CPE)

37Device Firmware Default settings

38HDM Tables

Section 1 | Document Overview

Document StructureThe document is organized in the following sections

Section 2Project OverviewGives and overview of the scope of the project and assumptions related to integration with OSS / BSS.

Section 3DesignThis section gives a description of the hardware architecture and Logical flow between Motive components and OSS / BSS.

Section 4Process CommunicationA description of the flow between the different Motive components is given here. Only the main use cases for each components are considered.

Section 5Logical Data DesignA list of data required for Motive solution to work is given here. This is mapped to the CSMS data structure.

Section 6High Level MTNL HSD and HDM Use casesA list of all the important use cases for the Motive components is listed here.

Section 7HDM User casesDetailed description of the 11 HDM use cases

Section 8ReportsA list of all supported reports is described.

Section 9AppendixAdditional information

Revision History

RevisionCommentsRevision dateAuthor

0.1Initial Draft20th May 2008Ajay and Jainendra

0.2Changes with review comments from Harsha for use cases and flow diagrams.4th June 2008Jainendra

0.3Change of template17th June 2008Ajay and Jainendra

0.4Addition of Appendix section and changes to Section 726th June 2008Harsha

1.0Final Review9th July Harsha

References

Source DocumentsThe following documents are relevant to this Customer Requirements Document:

Document nameDate and version

MTNL Activation Requirements 24th January 2008, Version 1.0

MTNL Reporting CRD 2nd February 2008, Version 1.0

MTNL Self Support CRD2nd February 2008, Version 1.0

MTNL CSM CRD8th February 2008, Version 1.0

MTNL HDM CRD 8th February 2008, Version 1.0

MTNL - NOC Prerequisites11th June 2008, Version 1.0

MTNL Communication Flow13th May 2008

Section 2 | Project OverviewOverview

This service deployment requirements document has been developed by Motive Consulting Services for review and acceptance by MTNL/System Integrator. It is imperative that project stakeholders thoroughly read and understand this requirements document as it formally defines the deployment requirements and deliverables for the Broadband Subscriber Activation System (BSAS) project. BSAS consists of Total Broadband Care (TBC), HDM and Reporting features.

The Total Broadband Care & HDM Project is comprised of four major product deployments for MTNL High Speed Internet Services:

Service Activation Manager (SAM) Provides MTNL with automated activation capabilities that enable subscribers or technicians to turn up high-speed data services themselves. The product configures all the necessary elements of a high-speed data service via a multiple fulfillment model CD/web activationand performs a variety of activities including a minimum requirements check; desktop, application and CPE configuration; event reporting and more.

Self Service Manager (SSM) Provides MTNL with a client that is installed locally on the subscribers PC. Using this client, subscribers can solve common problems they encounter with email, settings, and their broadband service with the click of a button. Not only does SSM improve the subscriber experience, but it also reduces calls into MTNL contact center and decreases the associated cost of supporting the subscribers. Customer Service Manager (CSM) Provides MTNL call center agents with detailed technical information in real time from a subscribers system to facilitate fast and accurate resolution to common support issues. Home Device Manager (HDM) Enables MTNL to remotely manage CPE, such as residential gateways, IP set-top boxes, and VoIP terminal adapters that comprise a home networking environment. The product offers single as well as large-scale bulk device configuration, troubleshooting, firmware upgrades, event management, user management and reporting, as well as a standardized CPE integration layer that gives providers a choice of CPE supported either by the DSL Forums TR-069 or Simple Network Management Protocol (SNMP).Scope Definition

The focus is limited to enablement of High Speed Internet Service. The deployment requirement document will cover HDM deployment & TBC integrations with external entities only.Assumptions The System Integrator will be responsible for developing an application based on EAI that provides a Web Service for HDM Northbound Interface (NBI) to load the subscriber data into HDM prior to the subscriber turning up the service. It is assumed that this MTNL application will make the new provisioning records available to HDM. It should be noted that if there are devices already issued and have firmware that has not been tested for interoperability with Motive HDM, before such devices can be fully managed remotely, the firmware will need to be upgraded. The process of upgrading these devices is defined as part of the firmware upgrade use case.

If the CPE devices are running in bridged mode, the firmware should ensure that these devices must acquire an IP address and make it available to HDM and must be able to intercept traffic destined for that IP address

HDM uses Connection Request (CR) for requesting a connection with the CPE. The CPE generates and sends this CR URL to HDM on the first inform as well as if this parameter is changed for any reason. If the firewall on the CPE is turned on by default, then the CPE firmware should be able to allow an incoming CR request and not get it blocked by its own firewall. This CR pass through should not be impacted by any subscriber configured firewall settings.Section 3 | Design

Overview

This section describes the Hardware configuration Architecture and Logical flow of communication between various components used for deployment.The Hardware configuration Architecture is subject to change if the desired hardware configuration is not used.

Logical flow provides a high level understanding of flow of communication between various components.

Hardware Configuration ArchitectureThe following Hardware Architecture of system is based on our understanding of the solution which captures the MTNL needs/requirement clearly.

Logical Flow

The diagram below depicts the interaction / touch points between OMS/Metasolv and the MTNL hosted deployments of HDM and Activation during new customer activation.

When an order is placed (#1) the fulfillment data is sent to MTNLs Metasolve application from the Order Management System. MTNLs Metasolve application provisions the order in relevant backend systems (#2) The subscriber receives the activation kit with the pre-provisioned CPE and starts the installation flows. (#3) The flows instruct the subscriber with connecting the CPE to their computer and the CPE connects automatically to the MTNL walled garden. The Activation flow contacts the HDM Bootstrap Server (#4) to initiate the device activation process. During the process Activation contact HDM to retrieves Subscriber information by calling GetUserInfo (#5). This process involves providing new credentials to the device and having the device contact the HDM Public Server. Once the device updates itself based on the information from the HDM Bootstrap Server, it (#6) contacts the HDM Public Server to complete the activation process. (#7) The SAM profile email, configure email in outlook with existing subscriber information and will also make a number of Internet Explorer configuration changes (home page and favorites).From this point on, the device can be managed remotely (#8). Section 4 | Process Communication

This section provides you communication flow between various motive components.Broadband Subscriber Activation Service

Here is description for CPE activation communication flow. SAM activates a CPE in PPPoE Username and contact HDM for device management.

Self Service Manager Customer Service ManagerThis process model provides how SSM fixes when subscriber has an issue with his broadband connection.

HDM Password RecoveryThis process model provides different components interaction when subscriber changes his password by login into a MTNL portal.

Section 5 | Logical Data Design

This provides logical view how data get stored/retrieve in different database tables and mapping between table in HDM and CSMS. To support MTNL Subscriber MTNL_SUBSCRIBER_INFO table needs to be created on the HDM database.

Customer Data ModelFollowing MTNL subscriber information is needed from CSMS System. The CustomerData xml is needed to insert/update/delete subscriber information used by HDM proxy to update HDM database. // Mandatory Can specify multiple CustomerData blocks

// Mandatory String Non Null





// Optional String


// Mandatory Number Non Null













// Optional String // Optional String MTNL Subscriber TableThe table stores MTNL Subscriber information, this information existing before subscriber activating the CPE using the CD.

Assumptions:

MTNL_Subscriber Table was getting populated from the CSMS database tables (it can be schedule job or on demand job).Column nameDatatypeNull?CSMS equal Column/Table

FIRST_NAMEVCHAR2 (50)NOT NULLUSER_FIRST_NAME/ MSUBSCRBR

LAST_NAMEVCHAR2 (50)NOT NULLUSER_SURNAME/ MSUBSCRBR

ADDRESS1VCHAR2 (60)NOT NULL

ADDRESS2VCHAR2 (60)

CITYVCHAR2 (25)NOT NULLRequired ?

ZIPNUMBERNOT NULLRequired ?

STATEVCHAR2 (50)NOT NULLRequired ?

REGIONVCHAR2 (50)NOT NULLRequired ?

PUBLIC_PPPOE_USER_NAME VCHAR2 (60)NOT NULL

PUBLIC_PPPOE_PASSWORD VCHAR2 (60)NOT NULL

EMAIL_DISPLAY_NAMEVCHAR2 (60) NOT NULL

EMAIL_USER_NAMEVCHAR2 (60) NOT NULL

EMAIL_PASSWORDVCHAR2 (60) NOT NULL

EMAIL_ADDRESSVCHAR2 (80)NOT NULL

EMAIL_POP_SERVERVCHAR2 (60)NOT NULL

EMAIL_POP_SERVER_PORTNUMBER NOT NULL

EMAIL_SMTP_SERVERVCHAR2 (60)NOT NULL

EMAIL_SMTP_SERVER_PORTNUMBER NOT NULL

DATE_OF_COMMISSIONVCHAR2 (20)NOT NULLINSTLTN_DT/ MSUBSCRBR

PACKAGE_DETAILSVCHAR2 (256)NOT NULLPLAN_CODE/XACSRYPLAN

PHONE_NUMBER(Primary Key)VCHAR2NOT NULLTEL_NO/ MSUBSCRBR

Section 6 | High-level HSD and HDM Use CasesThis covers the following high-level use cases which will be elaborated in detail within this document:

1. New Customer Activation First Run

2. Customer Multiple Activations

3. Customer Activation Second Computer

4. CPE Swap CPE1 User2

5. CPE Swap CPE2 User1

6. Care PAN for connectivity issue

7. Care PAN for e-mail issue

8. Care Telemetry offline and online

9. CSR Telemetry offline and online

10. CSR HDM Plug-in for call resolution

11. One click fixes

12. OSS Add MTNL User Information13. OSS Update MTNL User Information14. OSS Delete MTNL User Information

15. Enable/Disable Service on CPE

16. MTNL User Password Change

High-level MTNL HDM & Activation Use Case

The following high-level use case provides a quick overview of the project. Detailed use cases and requirements will be delineated within this deployment requirements document.

Activation Use Case: HDM and Service Activation Manager (SAM)

Precondition: Motive HDM server is pre-loaded with customer\device specific PPPoE credentials, email address\password and subscriber phone number and service address details. CPE is provisioned with generic PPPoE credentials.

Flow of Events:

1. Customer receives MTNL activation package after ordering the service.

2. Customer inserts MTNL activation CD and follows the instructions to wire\power the CPE.

3. Device connects to the MTNL network and is routed to a Walled Garden (Radius).

4. Device performs initial inform to the Motive HDM (Walled Garden instance) server.5. The SAM flow transfers flow control to the Walled Garden Activation web-flow

6. The activation SAM will conduct the following actions.

a. Upon launch of the SAM, the activation manager will prompt the subscriber or the technician to supply the subscriber ID & Password(to which the service has been provisioned)

b. The activation manager will retrieve the PPPoE credentials, HTTP credentials; email address\password, subscriber service address from the HDM system via the Northbound Interface (NBI).

c. Upon completion of the flow, SAM will update the device with the customers PPPoE credentials & TR69 HTTP credentials (the ACS URL, User Name and Password).

d. The SAM will setup the email account in either Outlook or Outlook Express.e. The SAM will make a number of Internet Explorer configuration changes (home page and favorites).

7. Upon application of the new configuration the device will reset and reacquire access to the MTNL network.

Section 7 | HDM Use Cases

Use Case #1 New Subscriber Activation First RunHigh-level description: A kit with a CD and a Motive Interoperability tested CPE will be sent to a new residential subscriber. The CPE activation will be started by interacting with HDM Bootstrap and HDM Management server but can only be completed successfully once the MTNL OSS provides the unique PPP credentials, user information and service details.

Sequence:

New Residential Customer Activation Scenario

Trigger: This use case is triggered when the user connects the device to their LAN and the device notifies the HDM bootstrap server that it is available. For the entire use case to complete, Activation CD instructions will need to be followed. The subscriber Information needs to be present in the HDM System before the activation can take place. Else the device will not be activated and the public credentials will not be applied on the device.

Step 0 Pre-configuration

The CPE (or the device as it will be referred interchangeably with term CPE) is pre-configured with the approved firmware version, default HDM Bootstrap server URL, default HDM credentials, and default PPPoE credentials. Step 1 CPE is plugged in

Following Activation CD prompts, after the CPE is plugged in and powered on, it will use default PPPoE credentials to authenticate with MTNLs DSLAM, and will receive a public/private IP address. The CPE is put on a public internet but with the access restricted by MTNLs DSLAM to HDM Bootstrap Server, HDM Management Server, and Activation Web Flow portal.

Step 2 HDMProxy retrieves and updates the User Info on the HDM device objectAt this time, the Activation CD has determined that the CPE is connected with the walled garden and it prompts the user to type the unique customer PPPoE User Name & password. The Subscriber account info is retrieved from the HDM database and updated subscriber information in CPE.

Step 3 Unique PPPoE, Pubic HTTP credentials and public HDM URL set on the CPE

Activation CD applies the public HDM Management server URL, and public PPPOE credentials on the device and the device is rebooted.

Step 4 CPE re-authenticates with DSLAM

As a result of setting new unique PPPoE credentials, the CPE will automatically re-authenticate with the DSLAM, will obtain a new public IP address that will allow access to the public Internet without the Walled Garden restrictions imposed by DSLAM in Step 2.

Step 5 Subscriber data is sent to HDMProxy ServletThe Subscriber account info is sent to the HDM database and updated on the User tags of the HDM device object corresponding to the external IP address sent via the HTTP post message to HDMProxy servlet. Device state was updated into activated MTNL_ACTIVATION_STATUS is set to true on the HDM device object.Use Case #2 Existing Subscriber Rerun of the Activation CD

Note: This use case only applies for subscribers who were previously activated using the Motive CD and a rerun is attempted.

High-level description: The CPE was already activated using the motive CD. But a rerun is attempted. The CD resets all the credentials to default values and also resets the ACS URL to WG URL. The CPE activation will be started by interacting with HDM Bootstrap server.Sequence:

Trigger: This use case is triggered when the user tries to rerun the activation CD after a successful activation. The device notifies the HDM bootstrap server that it is available. For the entire use case to complete, Activation CD instructions will need to be followed. The subscriber Information needs will be present in already activated HDM device object.

In this case a dynamic variable MTNL_ACTIVATION_STATUS is set to true on the HDM device object. Step 0 Pre-configuration

The CPE (or the device as it will be referred interchangeably with term CPE) is already configured with public PPPOE and HTTP credentials and is already talking with the public HDM server. Step 1 CPE is plugged in

CPE uses the public PPPoE credentials to authenticate with MTNLs DSLAM, and will receive a public IP address.

Step 2 HDM DM connectivity

The CPE sends a TR-69 Inform message to HDM DM Server with public HDM username/password.

Step 3 Subscriber data is sent to HDMProxy Servleta) At this time, the Activation CD checks if the ACS URL is either a walled Garden URL or the DM URL.

b) If it is either one, then the URL is left untouched. If it is neither one, then the URL is changed to the Walled Garden URL.

c) The activation CD now queries the HDMProxy to see if the device is already activated.

d) If yes, then the activation CD retrieves the user information from the HDM.

If the URL is a walled garden URL, the control flow is similar to the User Case #1.Use Case #3 Activation in Second Computer

This use case is exactly the same as the Use Case #2.

Use Case #4 Factory Reset

Description: If the user does a factory reset on the device, certain actions need to take place to reconfigure it. All values on the device will be reset to default values. Hence the ACS URL will be pointing to the WG server. Trigger: This use case is triggered by an Inform after Factory Reset from the CPE. Sequence:

In this use case, the activation happens without the aid of the activation CD.Step 0 Pre-configuration

The CPE (or the device as it will be referred interchangeably with term CPE) is reset. The ACS URL is set to the WG server and the PPPOE and HTTP credentials are all reset to the default values. Step 1 CPE is plugged in

Once the CPE is plugged in, it uses the default PPPoE credentials to authenticate with MTNLs DSLAM, and will receive a public/private IP address. The CPE is put on a public internet but with the access restricted by MTNLs DSLAM to HDM Bootstrap Server, HDM Management Server, and Activation Web Flow portal.

Step 2 HDM Walled Garden connectivity

The CPE sends a TR-69 Inform message to HDM Bootstrap Server with default HDM username/password. HDM Bootstrap Server assigns and sends Connection Request credentials to the CPE. Those credentials are needed for subsequent connection requests made by the ACS server (HDM in this case) to the device.

Step 3 HDM Walled Garden connectivity Inform Interval set to a Lower valueThe Walled Garden HDM server sets the inform interval to 30 Seconds on the device. Inform Interval is the time span between which the CPE sends Inform messages to the HDM.

Step 4 HDM Walled Garden connectivity OSSI java script is executedOSSI java script does the following:

a) It first checks if the MTNL_ACTIVATION_STATUS dynamic variable is set to TRUE. This will be true in case of the factory reset as the device would have been activated previously. If False, the CPE has never been activated and to activate the device, the activation CD would be required and the first use case needs to be followed.

b) If True, the OSSI script will retrieve the User information already stored in the device object of the HDM and applies the public credentials to the device. It also registers the device again with the HDM.


As a result of setting new unique PPPoE credentials, the CPE will automatically re-authenticate with the DSLAM, will obtain a new public IP address that will allow access to the public Internet without the Walled Garden restrictions imposed by DSLAM in Step 2.

Step 6 Activation Policy triggered

Once the device is rebooted and on the first inform of the device to the public HDM management server, the device activation policy is executed. The later sets the inform interval back to a higher value of 12 or 24 hours. Once the activation policy is executed successfully, the device activation status dynamic variable is set to true and the device is activated.

Use Case #5 CPE Swap: CPE1 User2Description: Customer User 1 activates CPE1 using the Motive activation CD. User2 now tries to activate the same CPE1 in his/her premises using the Motive activation CD.

Trigger: This use case is triggered when User2 tries to activate a CPE already activated by some other subscriber. Sequence


CPE should have to be reset before getting used by a different User. If no, the ACS URL, the PPPoE and HTTP credentials are all set to default values when the activation CD starts its execution.Step 1 CPE is plugged inStep 2 HDM Walled Garden Connectivity


Step 3 Subscriber data is sent to HDMProxy Servlete) At this time, the Activation CD has determined that the CPE is connected with the HDM and it prompts the user to type the unique PPPoE User Name & Telephone Number. The Activation flow sends the CPE external IP Address, User Name & Telephone Number to HDMProxy servlet via HTTP post message requesting the later to get The User Information.

f) HDMProxy first checks to see if the MTNL_ACTIVATION_STATUS is set to true. If it is true, then it means that the CPE1 - User1 device Object was not deleted from the HDM and is still active.

g) If it is true, the proxy checks if the device is already activated. If true, the subscribers PPPoE user name is verified against the subscriber information on the device.

h) If they match, the User Information is returned back to the User. From now on, the steps are similar to the Use Case #1 Step6.

If the subscriber information does not match, an Exception is thrown back to the caller stating that the CPE is registered with a different User.Use Case #6 CPE Swap: CPE2 User1Description: Customer User1 activates CPE1 using the Motive activation CD. User1 now tries to activate CPE2 in his/her premises using the Motive activation CD.

Trigger: This use case is triggered when User1 tries to activate a new CPE2 after activating CPE1. Sequence


CPE should have to be reset before getting used by a different User. If no, the ACS URL, the PPPoE and HTTP credentials are all set to default values when the activation CD starts its execution.Step 1 CPE is plugged in

CPE uses the default PPPoE credentials to authenticate with MTNLs DSLAM, and will receive a public/private IP address. The CPE is put on a public internet but with the access restricted by MTNLs DSLAM to HDM Bootstrap Server, HDM Management Server, and Activation Web Flow portal.

Step 2 HDM Walled Garden connectivity


Step 3 HDM Walled Garden connectivity Inform Interval set to a Lower valueThe Walled Garden HDM server sets the inform interval to 30 Seconds on the device. Inform Interval is the time span between which the CPE sends Inform messages to the HDM.

Step 4 Subscriber data is sent to HDMProxy Servleta) At this time, the Activation CD has determined that the CPE is connected with the walled garden and it prompts the user to type the unique PPPoE User Name & Telephone Number. The Activation flow sends the CPE external IP Address and the User Name & Telephone Number to HDMProxy servlet via HTTP post message requesting the later to Get User Info.

b) HDMProxy first checks to see if the MTNL_ACTIVATION_STATUS is set to true. If it is true, then it means that the CPE2 User% device Object was not deleted from the HDM and is still active.

c) If it is true, the control flow is similar to the above use case.

d) If it is false, then the proxy checks to see if there is a Device object corresponding to the subscriber information sent.

e) If no device is found for the User1 in HDM, the control flow proceeds like the Use Case 1 from now on.

If a device is found corresponding to the input subscriber information, then the former is soft deleted from the HDM system. Then the control proceeds like the Use Case 1.

Use Case #7 Add MTNL User InformationDescription: OSS system will add new MTNL subscriber information into HDM by doing a HTTP Post to the below URL.

https://:7004/HDMProxy?requestXML=

Trigger: OSS systems trigger this use case. This can be triggered as a periodic batch process dumping all the new User information into the HDM at one shot or can be invoked each time there is a new User registration into MTNL.

Step 1 Request XML needs to be constructed by the OSS

The request XML looks like as shown bellow:

InsertUserInfo // Mandatory String // Ref: Customer Data Model

Step 2 OSS posts the request XML to HDMProxy

HDM proxy adds the information received via the HTTP Post into the MTNL_SUBSCRIBER_INFO table in the HDM DB. This information would be used during the activation to associate a CPE with a subscriber.

Use Case #8 Update MTNL User InformationDescription: OSS system will update existing MTNL subscriber information into HDM by doing a HTTP Post to the below URL.


Trigger: OSS systems trigger this use case. This can be triggered as a periodic batch process dumping all the User information updates into the HDM at one shot or can be invoked each time there is a User update in MTNL.



UpdateUserInfo // Mandatory - String // Ref: Customer Data Model

Optional In this use case, attributes which are optional are the ones which are not changed. In case any of the attributes are changed, then they need to be specified. Step 2 OSS posts the request XML to HDMProxy

HDM proxy updates the information received via the HTTP Post into the MTNL_SUBSCRIBER_INFO table in the HDM DB.

Step 3 HDM Device object is updated

a) During each update, HDM DB is searched to find the device object corresponding to the subscriber being updated.

b) If device object is found, HDM proxy updates the information received on the device Object.

c) In case PPPOE credentials are changed during the update, the CPE needs to be reset to get the new credentials from the HDM.Use Case #9 Delete MTNL User InformationDescription: OSS system will delete existing MTNL subscriber information from HDM by doing a HTTP Post to the below URL.


Trigger: OSS systems trigger this use case. This can be triggered as a periodic batch process dumping all the User deletes into the HDM at one shot or can be invoked each time there is a subscriber cancellation in MTNL.



DeleteUserInfo // Mandatory - String // Ref: Customer Data Model


HDM proxy deletes the subscriber information received via the HTTP Post from the MTNL_SUBSCRIBER_INFO table in the HDM DB.

Step 3 HDM Device object is deleted

a) During each delete, HDM DB is searched to find the device object corresponding to the subscriber being deleted.

b) If device object is found, HDM proxy deletes the device Object from HDM.

c) MTNL should have disabled the DSLAM port before using this Use case to delete the subscriber information. This would prevent the user from using the CPE in case the CPE is not reset and is still getting used with public credentials.Use Case #10 Enable/Disable Service on the CPEDescription: OSS system can enable a service on the CPE device by doing a HTTP Post to the below URL.


Trigger: OSS systems trigger this use case.

Prerequisite: The CPE needs to be online to enable a service.



EnableVOIP // Mandatory String // Ref: Customer Data Model


HDM proxy would do the needful to set required parameters on the device to Enable/Disable the specified service.

Based on the types of services to be supported, there will be corresponding request types to enable and disable the service.

(Multiple services on a single CPE can be achieved using the different channels on the CPE. In some cases the channels may have to be configured in the bridged mode)Use Case #11 MTNL User Password ChangeDescription: User Visit MTNL website and change PPPoE password. User able browse internet, until he reboots the modem. Trigger: SSA triggers this use case. This can be triggered when User was not able to browse, when he open browser, get 404 page.

Sequence:

Password change scenario

Step 1 User restarts Modem, connect internet after changing password User restart modem and open web browser to connect internet. User was not able to browse(since CPE still has old password). User uses SSM to update the credentials and fix the connection issue.

Step 2 SSM Set the PPPoE credentials to the default value to connect to HDM and retrieve the updated user credentials.SSM sets default userid, password Restarts modem.

Step 3 HDMProxy retrieves and updates the password on the HDM device object

The CPE is connected HDM with devmgmt URL and The Subscriber account info is retrieved from the HDM database and updated the password HDM device object and reboot modem.


As a result of setting new unique PPPoE credentials, the CPE will automatically re-authenticate with the DSLAM, will obtain a new public IP address that will allow access to the public Internet.Section 8 | Reports

Reports can be generated from the system performance and incident data that the Motive system stores. These reports can show data submitted with each incident and subsequently collected during their resolutions as well as the ongoing status of Motive servers and applications.The categories of reports vary depending on the deployment of your Management Console. If custom reports are written, other categories can exist. The typical categories include the following:

Service Request ReportsInformation that summarizes the subscribers' service requests. These reports provide average service request resolution times, the distribution of service requests, and service request histories, and so on.

Content Usage ReportsInformation about evaluating the content of your site. These reports determine the volume of users, the number of search queries, the types of content used, and the content undergoing change such as content added, deleted, unused, or expiring.

Activation ReportsInformation about broadband activation for subscribers. These reports include machine configuration specifications, subscriber profile data, details about the activation process.Home Networking ReportsInformation about the deployed Home Networking flow.Phone Support ReportsInformation about performance and usability of Assisted Service Phone and Self-Service Phone support.

Service Request ReportsInformation about subscribers' service requests. These reports provide average service request resolution times, the distribution of service requests, and service request histories, and so on.

Remote Control ReportsInformation about the subscriber's Remote Control for subscribers who deploy the Remote Control functionality.CSR Productivity ReportsInformation for evaluating the productivity of CSRs. These reports show the number of open or closed service requests per CSR, the average resolution time of service request per CSR, and the total volume of assisted service requests per CSR.Content Usage ReportsInformation for evaluating the content of your site. These reports determine the volume of users, the number of search queries, the types of content used, and the content undergoing change, such as content added, deleted, unused, or expiring.Subscriber Usage ReportsInformation about subscribers' use of support. These reports provide subscribers' contact information, service request history, service actions, feedback, use of search queries, and contain client and portal data.Service Abuse ReportsReports that give detailed information about abuse events, and the actions taken to resolve them. You can use Crystal Reports Designer 10, which is provided with the Data Mart, to create custom reports.Detailed CPE Summary Report

This report is an extension of the General CPE Summary Report, and provides additional breakout by software version within a given device type. It lists counts of activated as well as total number of devices for each (device type, software version) combination. The report uses data from the DEVICE and DEVICETYPE tables.Parameters: NoneGeneral CPE Summary Report

This report provides a summary view of devices in the system, broken out by device type. It lists counts of activated as well as total number of devices for each device type. The report uses data from the DEVICE and DEVICETYPE tables.

Parameters: None

Detailed Device Status Report

This report provides a summary view of the devices in the system, broken out by device type and firmware version. In this case, the report lists counts of devices that have contacted Home Device Manager within four distinct time frames.

These time frames are:

Within the last 24 hours from the date the report data was refreshed. Within 1 to 7 days from the date the report data was refreshed. Within 8 to 30 days from the date the report data was refreshed. More than 30 days from the date the report data was refreshed. The report uses data from the DEVICE and DEVICETYPE tables.Parameters: None

Standard Report

Contact Failure ReportThis report is useful in identifying individual devices that have not contacted Home Device Manager within a specific period. For a given device, the number of days missed and the number of Inform periods missed (calculated based on the value of its Periodic Interval setting) are displayed. The report uses data from the DEVICE and its cached data record tables.

Parameters:

device_type_name: Specifies a device type to use for the search.

days_skipped: An integer value for the number of days to use. Any device of the specified device type that has not contacted Home Device Manager within this number of days is retrieved.

Detailed Device History ReportThis report is useful in obtaining detailed information about a specific device. For each device, the following kinds of information are displayed:

Manufacturer, model, software version, subscriber, HTTP user name, last contact date, periodic inform interval, activation status, external IP address, and so forth. User and service tags on the device, including their current values. Operation history on the device (including both management policies and single-device operations) with operation name, function/RPC name, cumulative success/failure/abort counts for each operation performed on the device, and last failure message, if any. For each operation, a drill-down to operation parameters is available in the HTML version of the report.

The report uses data from the DEVICE, DEVICETYPE, PARAMETERVALUE (cached data record), DEVICEUSERTAGS, and DEVICESERVICETAGS tables for device data. It also uses historical data from the DEVICEACTIONRESULT_LOG table for reconstructing detailed operation history.

Parameters:

device_type_name: Specifies the device type of the device.

serial_number: Specifies the serial number of the device.Policy Inventory ReportThis report provides a summarized view of policy execution statistics over a specific time period. Success, failure, and aborted counts are rolled up by policy to the granularity of a day.Parameters:

start_date: Specifies the beginning of the time period for the summarization.

end_date: Specifies the end of the time period for the summarization.

Policy Summary ReportThis report provides a detailed view of an individual policy, and includes the following kinds of information: Name of policy, selection criteria, function/RPC invoked, triggering method, whether the cached data record will be updated, and so forth. A summarized view of execution statistics for this policy over the specified time period.

The report uses historical data from the DEVICEACTIONRESULT_LOG table.

Parameters:

policy_name: Specifies the primary key (database ID) of the policy (the inconsistent name of this parameter will be fixed in a future release).

start_date: Specifies the beginning of the time period for the summarization.

end_date: Specifies the end of the time period for the summarizationSection 9 | Appendix

Supported Customer Premise Equipment (CPE)PrerequisitesBefore HDM can manage a device in the HDM Management Console, the following assumptions must be met.

The CPE (Customer Premise Equipment) must be certified for interoperability with Home Device Manager.

The device type data model associated with a device must accurately define the capabilities of the device to be managed by the HDM Management Console.

You must be familiar with the architecture, terminology, and concepts for the communications protocol supported by the CPE (for example, TR-069 or SNMP).

To run policies that affect SNMP devices, first you must enable certain SNMP timer task server properties and then restart the server. By default, these properties are not enabled in order to reduce timer thread overhead. CPE DeviceFirmware version

Device Firmware Default settingsThe CPE manufacturer will provide MTNL and Motive with a production firmware (pre-loaded on the delivered CPE devices) with the following parameters.Here is current list of information provided by the CPE manufacturer for BSAS project for the all their CPE.

MTNL ProductionDetails

Default ACS URLhttp://bootstrap.acs.mtnl.co.in/cwmpWeb/WGCPEMgt

Default ACS Usernamemtnlbroadband

Default ACS Passwordmtnlbroadband

Default PPPoE Usernamemtnlbroadband

Default PPPoE Passwordmtnlbroadband

Default periodic inform interval60 mins

SSL CertPublic key for the Root CA cert used to sign the HDM servers SSL certificates must be pre-provisioned on the CPE.

PPPoE PVC0

Default PPPoE Username

Default PPPoE Password

PPPoE Server Nametriband

PVC default ConfigurationPVC 0 Enabled: VPI 0 VCI 32, PPPoE Routed mode, NAT enabled, LAN DHCP Enabled, LLC/SNAP Authentication Auto

Dial on demand (idle timeout timer) disabled

PVC1: VPI 0 VCI 33, bridge mode, LC/SNAP




NAT and Firewall requirementsPVC1 Firewall and NAT enabled

SNMP Configuration

System.sysDescr.DMtnlbroadband

TR-64

Login usernameAdmin

Login passwordAdmin

SSLNo ssl

Firewall passthrough for TR64 clients

Lan Configuration

Lan UI usernameAdmin

Lan passwordAdmin

Lan IP Address192.168.1.1/24

Wireless configuration

Enable/DisableN/A

SecurityN/A

SSIDN/A

StandardN/A

ModeN/A

SNTP configurationBlank

DSL configuration Annex MDisable

GMPEnabled

HDM TablesThe HDM schema contains database tables organized into functional areas according to functionality. The functional areas are:

Policy and actions. This functional area contains tables relating to policies used to manage and activate CPE devices, and the CPE device information related to policy execution.

Selection criteria template. This functional area contains tables relating to device selection when executing actions.

Device. This functional area contains tables relating to CPE devices managed by Home Device Manager.

Object model. This functional area contains tables relating to the definition and activation of CPE devices per device type.

Core services tables. This functional area contains tables relating to the Home Device Manager environment.

Device management protocol. This functional area contains tables relating to the tasks performed by the protocol tier within the Home Device Manager server.

Authentication and Authorization Model. This functional area contains tables relating to the tasks performed by the HDM Authentication module and the authorization infrastructure.

Miscellaneous. This functional area includes a single table that defines the current version of the schema for use in future upgrades.Device TableIn the following section, we have provided the Device Table information. This device table contains the device information for a Customer Premises Equipment.

Column nameDatatypeNull?Description

ID(Primary Key)NUMBER(19)System-generated primary keyFormat: NUMBER NOT NULL

VERSION NUMBER(10)NOT NULL Indicates the version number of the associated record. The version number is used by Hibernate managed versioning for optimistic locking.Format: NUMBER NOT NULL

GUIDVCHAR2(32)NOT NULLIndicates the globally unique ID for the device.Format: VARCHAR2(32) NOT NULL

INSERTEDTIMESTAMP(6) NOT NULL Time stamp indicating when the record was created.Format: TIMESTAMP(6) NOT NULL

UPDATEDTIMESTAMP(6) NOT NULL Time stamp indicating when the record was last updated.Format: TIMESTAMP(6) NOT NULL

DEVICETYPE_IDNUMBER(19)A foreign key reference to the ID row in the DEVICETYPE table.

PROVISIONINGINFO_IDNUMBER(19)A foreign key reference to the ID row in the PROVISIONINGINFO table.

SERIALNUMBERVCHAR2(255)The OUID (Organizationally Unique ID) for the device. The serial number is unique within the scope of device type.

EXTERNALIPADDRESSVCHAR2(255)The IP address that connects the CPE device to the WAN side of the network, which is usually the Internet.

EXTERNALIPADDRESSNUMNUMBER(19)

SOFTWAREVERSIONVCHAR2(255)The software version for the device (from the object-model parameters InternetGatewayDevice.DeviceInfo.SoftwareVersion or Device.DeviceInfo.SoftwareVersion) is retrieved from the Inform parameters and stored in this first-class attribute of the DEVICE table. Since SoftwareVersion is a required Inform parameter, the value in this column should be very up-to-date. It should be used in device selection-criteria where software version is a criterion, since that will be more efficient than traversing the hierarchical cached-data record for the device.

CONNECTIONREQUESTURLVCHAR2(255)The URL on which a CPE device listens. When a CPE device contacts the HDM server, it reports its URL. The HDM server can then issue a connection request to this URL, which causes the CPE device to contact the HDM server.

FIRSTCONTACTTIMETIMESTAMP(6)The time at which the CPE device established first contact with the server.

LASTCONTACTTIMETIMESTAMP(6)The time at which the CPE device last contacted the server.

SUBSCRIBERID(Reference: MTNL_Subscriber)VCHAR2A unique arbitrary string to identify a subscriber. The subscriber ID does not represent a foreign key relationship in our system.

ACTIVATEDNUMBER(1)Indicates whether a CPE device has been activated.

MANAGEDNUMBER(1)Indicates whether a CPE device is being managed by the HDM system.

DELETEDNUMBER(1)Indicates whether an object has been logically deleted. The data store maintains a history of all objects ever created and uses this flag to indicate which ones have been logically deleted.

CAPTUREDNUMBER(1)Indicates whether a device is in manual mode (captured) or automatic mode.

LASTACTIVATIONTIMETIMESTAMP(6)Time stamp indicating when the CPE was last activated.

LASTCAPTUREDBYVCHAR2(128)The user name of the administrator who last locked the device for performing single-device operations.

LASTCAPTUREDTIMETIMESTAMP(6)A timestamp corresponding to the time the device was last locked for performing single-device operations.

CACHED_DATA_RECORD_IDNUMBER(19)A foreign key reference to the ID row in the DATARECORD table.

NULLINDICATORVCHAR2(64)Indicates that there is an allowable exception to a constraint set in this table. For example, a non-unique serial number is allowed if it only appears in a deleted record from the table.

GATEWAY_IDNUMBER(19)A foreign key reference to the ID row in the DEVICE table. A reference to the gateway device that is associated with this device. Device-gateway association models apply when the device implements the TR-111 specification (Part I). The reference will be present only if both device and its gateway are managed by HDM, and the device-gateway association information has been either gathered automatically through an Inform, or has been explicitly retrieved.

GATEWAYASSOCSTATUSNUMBER(10)Status of the device-gateway association. For this release, the only supported value is 0, indicating that the association value sent by the device via notification is stored in the system, but no additional cross-checking is performed.

GATEWAYASSOCTIMETIMESTAMP(6)A timestamp indicating when the device-gateway association was lasted updated.

UDPCONNECTIONREQUESTADDRESSVCHAR2(255)Address and port to which the ACS may send a UDP connection request to the device. This is extracted from the object model parameter Device.ManagementServer.UDPConnectionRequestAddress of the device. Only applicable for devices supporting the TR-111 protocol and has STUN enabled.

NATDETECTEDNUMBER(1)For devices supporting the TR-111 protocol and with STUN enabled, this flag indicates whether the CPE has detected if address and/or port mapping is in use. This is extracted from the object model parameter Device.ManagementServer.NATDetected of the device.

NATCONNECTIONREQUESTURLVCHAR2(255)The URL to which the ACS sends connection requests when using the NAT method. See Communicating with LAN devices that support only TR-111, Part 1 for more information. Only applicable for LAN devices configured to use port-forwarding on the associated gateway for connection requests.

PORTMAPPINGRETRYCOUNTNUMBER(10)The number of times the automatic port mapping configuration was attempted on the gateway and failed. The automatic port mapping operation will not be re-attempted for this LAN device if the value of this column exceeds the limit configured in the server property tr111.nat.port.mapping.retry.count. The value is reset to 0 on success. Only applicable for LAN devices configured to use port-forwarding on the associated gateway for connection requests.

CUSTOMATTR1VCHAR2(255)Auxiliary column that can store any device-specific information; can be populated by a SQL script or the NBI. Intended to be used by the selection criteria expressions.




CUSTOMATTR5NUMBER(19)Auxiliary column that can store any device-specific information; can be populated by a SQL script or the NBI. Intended to be used by the selection criteria expressions.

HDM PPPoE password not same as the password stored in the Router Profile.

uname/pword

HDM connectivity with unique HTTP uname/pword

CPE Public IP

Unique PPP U/P

5

CPE applies new configuration with unique credentials

and optional WG to public IP

4

Public CPE credentials set on CPE

CPE CR Cred & Inform

Interval set to 20 Sec

3

Public PPPOE credentials & Subscriber Information are

retrieved from HDM device object.

Inform (CPE WG IP)

2

WG_HDM connectivity with default HTTP uname/pword.

CPE CR cred assigned

CPE WG IP

Default PPP U/P

EMBED Visio.Drawing.11

DSLAM &

BRAS


Default HDM URL,

Default HDM U/P

[Default PPP U/P]

1

CPE authenticates with

DSLAM using default PPPoE, DSLAM restricts access to

Walled Garden

0

Factory reset, resets all credentials to default values and resets the ACS URL to WG URL

CPE

HDM DM

Server

HDM PPPoE Password same as the password stored in the Router Profile.


3

Fetch the PPPoE password from the HDM.

2

Default PPPOE credentials are set on the Modem & Modem is rebooted.

Password changes for DSLAM and HDM Server.

User changes password on MTNL Portal

DSLAM

Re-authenticate with DSLAM.

Fetch PPPoE password.

Recreate router profile. And re-authenticate with DSLAM.

4

5 WG_HDM connectivity with default HTTP uname/pword.


Subscriber (Subscriber ID, CPE ID, OUI, Serial Number ) sent from

Activation CD to HDMProxy (Using HTTP Post)

SubscriberID, CPE ID,

Request Type - Activate

Config (CPE config)

set the Inform Interval

to Large Value

6

Inform (device_ID)


4



3

Public CPE credentials set on CPE

Public Credentials, User Details



2


retrieved from HDM DB. Data Updated on the HDM

Device Object

Inform (CPE WG IP)

CPE WG IP

Default PPP U/P


DSLAM &

BRAS


Default HDM URL,

Default HDM U/P

[Default PPP U/P]

1

CPE is plugged in, powered on, authenticates with

DSLAM using default PPPoE, DSLAM restricts

access to Walled Garden. WG_HDM connectivity with default HTTP uname/pword.


0

Pre-configuration

CPE

Activation

Web Server

HDMProxy

HDM DM

Server

HDM Bootstrap

Server

Set password in CPE/care profile.

1


DSLAM using default PPPoE. The connection fails. User clicks the link I am Unable to Browse the Internet on the SSM.

0

User Changes Password on Portal

CPE

MTNL Portal

Care profile

HDM DM

Server

All credentials are retrieved from HDM Device Object

3

Activation CD checks if the CPE is already activated. If yes, then retrieve the User Information

Inform (CPE IP)

2

HDM connectivity with public HTTP uname/pword.

CPE public IP

Public PPP U/P


DSLAM &

BRAS


Public HDM URL,

Subscribers HDM U/P

Subscribers PPP Credentials

1


DSLAM using public PPPoE, DSLAM restricts access to

Walled Garden

0

CPE

HDM DM

Server

HDM Bootstrap

Server

Customer PC

CSM Console for Help Desk

A

C

P

E

Activation Server

HDM Server

DSLAM/ BRAS

Reporting Server

2. Care Server and HDM Server passes necessary details to CSM Server

3. Care Server sends one click fixes to the Care client

2

3

C

P

E

A

1. Care client contacts Care Server based on need (using PPPoE Unique Username)

1

4. HDM Server contacts the CPE directly for Service Activation and other flows

Database Server

Customer PC

4

A

C

P

E

Activation Server

HDM Server

HDM Proxy

Reporting Server

SAN

Activation

Unique PPP U/P

6


and optional WG to get public IP

3

If CPE1 is connected from User2s telephone, the DSLAM should block User2 from accessing net with User1s Credentials

CPE public credentials and HDM URL would be applied to CPE

3

CPE1 public credentials already stored in the HDM device object are applied to the CPE by the Activation CD

SubscriberID (User2), CPE ID & Telephone Number Request Type Get User Info

3

Subscriber (User2) (Subscriber ID, CPE ID & Telephone Number) sent from Activation CD to HDMProxy (Using HTTP Post)

5

User2 would receive an error saying that CPE1 is already registered with a different User

CPE1 User information is verified against the information received from activation CD



4

CPE1 activation status is verified. If true, the user information is retrieved and verified against the information received from the activation CD.

Inform (CPE WG IP)

2



CPE WG IP

Default PPP U/P


DSLAM &

BRAS


Default HDM URL,

Default HDM U/P

[Default PPP U/P]

1

CPE1 is plugged in, powered on, authenticates with


Walled Garden

0

Pre-configuration

CPE

Activation

Web Server

HDMProxy

HDM DM

Server

HDM Bootstrap

Server

Care

CSM Server

Care Server

3. Activation Client to Activation Server (using PPPoE Unique Username)

3

The above three flows complete Activation

2. CPE contacts HDM (using mtnlbroadband/mtnlbroadband)

2

1. Activation CD on CPE contacts HDM Server via HDM Proxy (mtnlbroadband/mtnlbroadband)

1

HDM Bootstrap

Server

Set password in CPE from care profile.

3. Care fetches HDM password. HDM PPPoE password not same as the password stored in the Router Profile.

4. Care Set password on the CPE. Recreate router profile. And re-authenticate with DSLAM.

2

2. CPE authenticates with DSLAM using default PPPoE. The connection fails. User clicks the link I am Unable to Browse the Internet on the SSM. Default PPPOE credentials are set on the Modem & Modem is rebooted. Fetch the PPPoE password from the HDM.

1. User Changes Password on Portal

3

Database Server

SAN

Activation

Care

CSM Server

Care Server

HDM NBI

4

1

OSS / BSS

Database Server

Customer PC

CSM Server

Care Server

Care

Activation

SAN

Reporting Server

HDM Proxy

HDM Server

Activation Server

6

Inform (device_ID)

Inform interval set to a Higher value of the CPE

7

Activation Policy Runs to


to Large Value

Config (Unique PPP U/P,Pub-HDM URL, Unique Pub-HDM U/P)

Config (CPE config)

HDM Bootstrap

Server

HDM DM

Server

HDMProxy

Activation

Web Server

CPE

Pre-configuration

0

CPE2 is plugged in, powered on, authenticates with


Walled Garden

1

Default HDM URL,

Default HDM U/P

[Default PPP U/P]


DSLAM &

BRAS


Default PPP U/P

CPE WG IP



2

Inform (CPE WG IP)


retrieved from HDM DB. Data Updated on the HDM

Device Object

5



Public Credentials, User Details

Public CPE credentials set on CPE by the Action CD

6

CPE2 applies new configuration with unique credentials


7

Unique PPP U/P

CPE Public IP


8

Inform (device_ID)

Subscriber and service configuration set on CPE

9

Activation Policy Runs to


to Large Value

Subscriber (Subscriber ID (User1), CPE ID, Telephone Number) sent from

Activation CD to HDMProxy (Using HTTP Post)

3

Config (Unique PPP U/P,Pub-HDM URL, Unique Pub-HDM U/P)

Config (CPE config)

SubscriberID (User1), CPE ID & Telephone Number Request Type - Activate

Any device associated with User1 is deleted from HDM

4

Delete any device associated with User1

_1263905983.vsd

_1263906404.vsd

_1263907787.vsd

_1263907788.vsd

_1263906405.vsd

_1263905984.vsd

_1240219513.vsd

_1240225442.vsd

_1240225443.vsd

_1240219512.vsd

mtnl delhi hld_motive 1.0

Documents

hdm use cases section

designthis section

hdm tables section

important use cases

main use cases

hdm use casesa list

addition of appendix

following sections section