Blansh
Technologies
Targeted applications:
Broadband Network System Management
Retail Chain and Warehouse System Management
Manufacturing System Management
Completeness of design and life cycle
List of tasks we have done for your project
Partnership opportunity - marketing
Intranet-based Management System Framework documentation (these pages require log-in authorization from Blansh Technologies):
GUI Managed Elements Status Tree
Broadband Network Control Reference Implementation
Broadband Network Control: Modem Simulator
Broadband Network Control Demo - back end simulation.
This page describes the process and scenarios implemented in the back end of the Broadband Network Control Demo : transactions between the Agent Server and DSL Modem hardware. In order to implement these scenarios the Modem Simulator was developed to replace real hardware in the development, integration and testing stages. It is a part of our Demo System. To see the architecture of the system refer to Targeted applications : Broadband System Control .
Note: The scenario described below and shown during the demonstration is only one of the few scenarios we developed to simulate the back end Modem hardware and this way to show the functionality of our Agent Server in it's support of back end Broadband network elements.
Below list is a DSL Modem Boot scenario which is driven by the event generated by the power up event of the DSL hardware. The JAVA Tester running as independent process simulates a DSL Modem by generating requests messages, processing the responses and maintaining a status.
Powered up
DSL Modem broadcasts a DHCP Requests over the subnet.
Agent
Server's DHCP Server responds by issuing an IP address from it's
pool.
Modem sends
a Registration message to the Agent (same IP address as a DHCP
Server) providing it's ID and all it's superior Network Elements
IDs to identify itself.
Agent starts
a respective scenario upon the receiving of the Registration
message. First it verifies if this Modem and it's superior
Network Elements are present in the Database records. If not
present, such records are created by the Agent given the
provided Ids.
Setting
internal time of the DSL Modem by sending a message containing a
time stamp. This is implemented as a <time sync> between
the Agent and it's managed Network Elements.
Agent sends
a StatusRequest message to the Modem. This is a solicitation for
a status report.
Modem
responds with a StatusReport message. It contains information
about it's overall status as well as it's contained cards.
Agent
updates the respective Database records with detail status of
the reporting Modem.
Agent spawns
internal timer for the periodic polling of the booted Modem.
From this moment it is engaged and after the current Boot
scenario expires, a TimeoutStatusReport scenario will be started
in the Agent by this timer (see below).
Agent issues
a Programming System Information to the booted Modem in 3
messages. First message carries a Transport stream related
parameters. Second message sends the Program Allocation Table.
Third message sends an authorization tables for this Modem's
assigned customers (permission key for each channel).
Note: although our implementation of the Programming System Information is based on the tables used in the industry, we don't consider it to be <blind copied> to the targeted system and therefore no detail documentation is provided for our implementation.
All the transactions are logged according to the Log Level into the Log files Vserver_err.log and Vserver_msg.log respectively. Each message content is printed out field by field.
Automation of the creation of customer records
As this Reference Implementation Demo created for the real life Broadband network, the solutions were developed to eliminate many problems typical for such systems. This problems are related to the creation and removing of the customer records. Relying the entering of customer records only on the operator leaves it to the good luck to not make mistakes when associating a customer with it's point of connection. We automate this process by implementing an Agent's scenario to create a Default Customer record for all new points of connections when a Network Element powers up. A notion of the Default Customer allows some default channel permissions to be assigned to the given connection, allows a technician to perform a test while connecting a customer settop box even before a <life> customer is entered into the database. Operator creates a <life> customer record by updating the Default Customer record chosen from the database by it's connection point (Network Elements Ids).
If <life> customer was assigned (connected) to the connection point, it's record will always be preserved in case of the failure of the Network Element or power down. Whereas a Default Customer records will be deleted in such cases. Such solution helps to eliminate many possible operator mistakes while operating upon customer records.
