NETWORKS (SDAOTN)

BACKGROUND OF THE INVENTION

The present invention relates generally to the telecommunications (Telecom) industry and, more particularly, concerns a uniform platform/system which automates the process for network maintenance, planning, expansion and optimization. A method and system provide solutions to all day to day needs of the Telecom industry to manage a complex network and realize reduction in manpower needs. Through automation, it reduces the chances of "human error. " Operational and integration issues have been resolved over the years in multi vendor systems but still there is a dire need for having one platform support for all needs. Software, tools, and processes have been created to solve smal l portions of the problem, but overall impact is missed, since it involves a large number of variables.

In the past, since networks were small, inter-vendor operations could be managed by employing a manageable work force , but now since the network have assumed much larger proportions, operators are employing an army of people for manual efforts, which is getting very expensive and also prone to "human errors. ^"

The invention provides a system which revolves around collecting data and processing it intelligently to minimize human effort to reach day to day decisions for maintaining a Telecom Network. Decisions are based on analysis and correlation of processed statistics from collected data to derive steps to improve and expand the network. The system is dynamic and responds to changes in traffic plan and call modeling. The proposed changes are only implemented after they are agreed to and sanctioned by proper authority. All scripts and steps are prepared and executed automatically after "proper authorization" during a maintenance window, thereby causing minimal down time.

All the changes are proposed only after taking into account of the whole network and not a part of the network.

A system embodying the present invention either employs FTP engines to input/dump the data at regular intervals from all switching (packet and core) components from the network, or to tap into existing raw databases like Kingfisher to extract data and convert it to useful audits, traffic utilization and performance related data. The system is based on Unix/Windows operating systems and on top of this layer is Oracle or similar database. The application runs on top of this database on a server like DOT NET , JA VA or the like.

Multiple conversion engines are built into software embodying the invention, depending on various vendors for circuit and packet switches like Ericsson, Nokia, Alcatel, and Motorola. These engines work as decoders to convert raw data of every system to one standard platform which this software needs to extrapolate information and provide intelligence to data to relate into a potential problem and then suggest ways to solve this problem.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing brief description and further objects, features and advantages of the present invention will be understood more completely from the following detailed description of a presently preferred, but nonetheless illustrative, embodiment in accordance with the present invention, with reference being had to the accompanying drawings, in which:

Fig. 1 is a block diagram illustrating the preferred architecture of a system embodying the present invention; FIGS. 2 and 3 are screen prints of two steps in the Port Management process; and FIGS. 4-8 are screen prints of steps in the Script Generation process.

DETAILED DESCRIPTION

A preferred system embodying the present invention utilizes a client/server architecture, which is preferred for networks requiring a high degree of reliability, the main advantages being:

Centralized Resources- given that the server is ihe center of the network, it can manage resources that are common to all users, for example: a central database would be used to avoid problems caused by redundant and inconsistent data.

Improved Security- as the number of entry points giving access to data is not so important.

Server Level Administration- as clients do not play a major role in this model, they require less administration.

Scalable Network- with this architecture it is possible to remove or add clients without affecting the operation of the network and without the need for major modification.

FIG. 1 is a block diagram illustrating the preferred architecture of a system embodying the present invention. The system has following modules, engines, or applications:

• Data gathering engine: This process FTP/Dumps the data at regular intervals into a daily/hourly file set. After the files are dumped another process/engine analyzes the data and after proper scrutiny it is processed and dumped in Oracle or a similar database. At this stage data consistency is checked by set of logics and inconsistent data is filtered out.

• Data Loading Engine: This engine is triggered by the data gathering engine and is responsible for loading relevant data to the oracle database. Data is loaded to the database based on field processing logics. Data is analyzed for error correction by a Record Selection module and, based on an algorithm, and the decision is made if the data is complete and accurate. Accurate data is sent to loaders for loading into the database and bad or incomplete data is sent to bad or discarded file. These files can be later analyzed to find the cause of incomplete data.

• Reporting Engine: This applications runs on top of the database to provide user interface for the system and provides users a common access to all the platforms, network performance charts, dashboard's KPIs, scheduled tasks for authorization, network planning, forecast and budgeting.

• Web Interface: Web interface displays all the information generated by Reporting engine on platforms such as Java or Dot net. also performs as central alarm monitoring system through touch screen at any remote locations.

• Alarm Triggers: Alarms are triggered if KPIs degrades such as any particular utilization crosses a threshold or any other particular conditions are met. These alarms are displayed on Web Interface, emailed or automatic voice calls are generated depending on the severity of the situation. These triggers are also sent to "System Dimensioning Network" Engine.

• Telnet Client: Telnet Client is induced when a set of commands have to be executed on the Network Node after proper authorizations are provided by touch screen or otherwise.

• System Dimensioning/Performance Application: This application runs in parallel to the other reporting engines acting as a "think tank" of the network. As soon as some alarm is triggered this can be system effecting, reduced KPIs or expansion needs based on utilization. All these triggers are sent to this application, which provides a solution for a problem by extrapolation and co-relation of the data to already resolved triggers. Once solution is derived all the scripts are created and are ran into the system by telnet client after "proper authorization"

Data Gathering Engine

This engine has the following processes: Data Collection and Polling:

The data collection as shown in the diagram happens from various network components such as OSS and BSS. The data can come in the system as defined on the OSS. The interval could be as short as 1 5 minutes. This data col lection interval is customizable. The raw data is either extracted from database or data is parsed from the raw data files. The data is then fed to the KPI parser where PI load maps are defined as per the vendor definitions and are inserted into the database. The primary key is the combination of the UID (CGI) and cell name. This is unique in nature and allows database to form a solid primary key which also helps integrate with the various other systems which have similar primary key.

Every UID will be associated with NC and MSC which will be the part of the definition of the hierarchy of the system. The association is required to define various KPI aggregations for the various network elements for different time intervals. The backend scripts have SNMP daemon installed which check for new data availability at a customized interval. Whenever there is data available the time stamp (start time and end time) of the available data and the interval for which data has arrived is checked back with the backend database. If the data does not exist or the data is different than previously loaded data then the transfer for the new data begins. The parsers load the data into the system which also kicks in processes for summaries to run. The summaries are over written for running KPIs for hourly, daily, weekly, monthly, quarterly and yearly KPIs. If there are missing data intervals for the data then periodically the system checks the availability of the missing data at the data source location. If the missing data is available then the transfer of the file takes place and files are queued to load to the parser when the regular load is available. All the data will be loaded using UTC time and for the display of the time will be translated to user's location. After each operation on the server, log fi le will be generated to log activity on the product which also helps development team to troubleshoot a problem. The 1 5 minute data will be loaded in the system within 4-5 minutes (It also depends on the hardware which is used). The data loading will be done via multi-threading, which will ensure faster data loads. All the threads will run in parallel for various schemas. This will ensure various processes run simultaneously in sequence.

Data Connections

The data which is transferred between the source such and BSC, MSC, RNC, OSS, BSS etc will support standard interfaces such as SSH, FTP, SFTP, SNMP. Data Loading Engine

This engine has the following processes: Data Aggregation

The aggregation with respect to time happens when new data is available in database. Various summaries run simultaneously in order to update all defined PIs for various time intervals. This is a defined process where the data is run sequentially and hence the output of the system is updated after every process. Data aggregation will start at the very bottom level and will grow north bound of the hierarchy. While data aggregation, depending on the KPIs various aggregation methodologies are used such as total, average, count, standard deviation etc. Data will be archived on a regular basis which will provide data integrity at all the levels.

Along with the hourly, daily, weekly, quarterly and yearly summary, there will be also Busy Hour data which is summarized on the basis of volume of traffic. There could be more definitions of the data which could be added for more busy hour calculations. Different Busy Hour calculations which can be supported are. Cel l Busy Hour, SDCCH Busy Hour, Route Busy Hour and Network element Busy Hour.

The data aggregation also supports mathematical functions such as exponential smoothing, moving averages, and standard deviations. It also takes into consideration of seasonality to evaluate performance affecting seasonality. Missing Data Recovery

There are instances where the data is not available at the source or some processes hang which causes missing data. There are two approaches which will be supported in the implementation, the first will be the auto data recovery, which will check the data availability at some predefined interval and check for the missing data and will look for the missing data at the source. Once the data is found it will be transferred and will be loaded in the system. The second approach will be the administrator will be monitoring the data at all the times and the data which is missed by the regular loading or auto recovery will be loaded using manual scripts. The data which is missing at the source can be manipulated if needed by taking same day and same hour data for the last week. Data Storage and Backups Data storage is one of the key areas in which we try to optimize the data in best possible way which will ensure better data and storage space management. The distributed table structures ensure that data will be flat and also provide fast access to the queries which will ensure faster data delivery and better user experience. The HOLAP will be installed in-house which will distribute the data between relational database and specialized storage. There will be auto backup which will be setup which will ensure data backup on a regular basis. Our backend team will ensure manually as well when the backup is completed to ensure secured data. The data storage throughput will be monitored by the administrator and will keep the data under manageable control. While the backups are running, we will be able to read and write on the database for uninterrupted operation.

Data Availability

Data availability determines the performance of the system, hence it is important to get data loaded as fast as we can to the system and we provide data to the users in the best possible ways. As this is a client-server environment, there is server and client caching which is provided for faster data access. The data is loaded in the system and is available from the user interface immediately. The distributed architecture ensures that if any of the hardware/software fails; the complete system does not go down, hence providing better availability. Other Data Loads

Any other new data sources which need to be added on regular or irregular basis will need to follow certain format which will help us to correlate the data with the existing database and hence could export to our database and normalized for usage.

Reporting, Web Interface and Web Schedulers

These applications run on top of the database to provide user interface for the system and provides user a common access to all the platforms, network performance charts, dashboards, KPIs, scheduled tasks for authorization, network planning, forecast and budgeting. Web interface displays all the information generated by Reporting engine on platforms such as Java or Dot net, also performs as central alarm monitoring system through touch screen at any remote locations. The following processes are performed: User Dashboard

When users login the system. Network Dashboard wi ll open by default which will show various graphs, alarms, alerts, data grids which will show overall health of the network. This will show various color coding schemes where data is color coded in combination of the real time statistical or parameter data compared with the predefined thresholds, goals and categorized by the various severity levels. The severity levels and threshold will be controlled by the administrator. The reports can be expanded and also have capability of logical and business process drill down. Dashboards can be coupled with user profiling which will allow customization of the dashboard for every individual. The Dashboard will have auto refresh functionality which will ensure data refresh when new data is available. Most of the Near Live Data reports will be sourced out of the dashboard and will show the live data through the website which will allow less load on the system as only users who need to find more details will go to the more detailed data version and hence not putting unnecessary load on the system. User Menu and Tabs

Every network element when clicked on it will show the menu items related to that network element. Cell Sites will have different menus from the BSC or MSC menu. The User menu is also available from the map where user can click on the menu and retrieve the next set of data. When clicked on the particular menu will open up a new tab which will ensure that your previous work area can be restored by clicking on the previous tab.

Predefined Reports

In order to provide faster access to the reports and to limit the load on the database, we store the pre generated reports based on the customized time intervals and store it in the database. This minimizes over crowding of simultaneous queries fired at the morning time when everyone gets in the office and allows faster access of the commonly extracted data. These reports are saved in the system forever hence can be accessed at any time. The reports can be sorted by simply clicking on the column as ascending or descending. Trending and Table Reports In order to view various reports in graphical tends, we provide different charting options. The reports can be shown in line, bar, pie chart for two dimensional reports. For three dimensional reports bubble chart can be shown to show the trending. Various trending reports are combined in a single report to address various PIs as well as various time intervals. The chart trend also has option to change the PI matrix. This allows user to select different types of trending on the same tab. In three dimensional trending, there is an auto play option available which shows the moving time window to see the moving trend. The reports can be sorted by simply clicking on the column as ascending or descending. Some of the table reports will have drop downs to mark the cells with pre- stored reasons and resolutions which will be easy way of marking the network elements.

Comparison Reports:

To compare the performance of certain KPIs, comparison reports can be used which allow users to select required KPIs and select the separate dates and retrieve the data. This also color codes data into different formats. Before and After Reports

To monitor any activity and its impact on the network it is essential to check the before and after performance of the network after any activity. Generally it is very difficult to analyze the vast amount of data for various KPIs using manual reporting. This feature allows users to select a single entity or group of entities and compares its performance and highlights problem areas using pre defined thresholds. The report is also shown graphically which shows easy to grasp summary of the data across various KPIs. The time periods could be single or multiple hours or any combination of the day to have flexibility to the user. This feature will be available for all the various network elements.

KPI Editor Every report wil l consist of KPI editor which wi ll enable user to change the KPI from the menu. KPI editor will also consist of various time intervals along with type of reports. It will also have the calendar option to select particular start date and end date. User Defined Calculation will be available for the Administrator, as the calculation of the data and its load to the system will have to be evaluated before it rol ls out to the production environment.

Custom Report Builder Custom Report Builder allows user to apply various conditions and rules on the data which will filter the required data for the user. It will also provide scheduled reports option. This will allow user to define particular report and when the report is available it will be emailed to the user. Logical Drill Down

Logical drill down depends on the business process and technical troubleshooting flow and allows digging deep from the available high level data to minute detailed data in steps. This also provides user details and shows affected levels of hierarchy and helps user troubleshoot a problem. GIS based Reports

The GIS based mapping is available where the all the cells in the network can be mapped on the web based GIS interface. This will also support thematic mapping of various layers which can be mapped on the basic layers.

Data Exports, Graph Exports and Printing Support Every report and graph has option to export the data. The data can be extracted into * . CSV,*. XLS format. The graphs can be saved as pictures supporting metafile, advanced eta file, bitmap, JPG, GIF, PNG formats. Reports are also supported in *.TXT or * .PDF format. The tool also supports print option for all the features supported.

Legends All the reports, graphs and maps show a tab for legend. This legend is interactive, where the use can choose to display elements on the graph and map which is controlled by the legend. The legends are color coded by default and use 65 bit colors to choose various colors on the scale. The hide and show function is also supported with the legend.

Knowledge Sharing In order to share the best practices and keep on sharing the information, the tool also provides platform to write comments on every network management element. This will provide the stage to share the best practices and will help keep the log of the system at all the times. This feature is more is useful for the cross functional groups.

Alerts and Alarms Various Alarms and Alerts are programmed on the application side as well as on the system side to ensure that the application availability to the user is continuous and provide high quality. Alerts and Alarms are customizable for table space, system load, total space, queries taking long time to run etc. On the application side, if any network element shows unexpected behavior then alarm is generated and the alarm pops up on the user screen.

System dimensioning / performance application has following components:

1 ) Acquiring Knowledge Base by means of collecting information from all elements

2) Processing "Knowledge based data" to reach to a decision making capability using a co-relation engine.

3) Executing decisions automatically to bring changes in the Network as desired.

4) Monitor changes and capabilities to enhance or revert back changes in case key Performance Indicator's show decrease in performance.

5) Utilizing the idle time on any element in the network to do simulations to verify, create and improve system models for future implementation.

This application performs the following processes:

Alarm Triggers: - Alarms are triggered if KPIs degrades such as any particular utilization crosses a threshold or any other particular conditions are met. These alarms are displayed on Web Interface, emailed or automatic voice calls are generated depending on the severity of the situation. These triggers are also sent to "System Dimensioning Network" Engine.

Fault Analysis: - Alarm and degradation of KPIs are analyzed to find a cause of the problem. If the fault is analyzed as hardware or software errors traffic is re-routed to other network elements so as to avoid any customer accessibility of the impact.

Traffic Balancing: - If KPIs point to congestion in a part of the network, bandwidth is increased to improved congestion or Hardware Expansion is sought in case the capacity is reached. Network Optimization: - Network is optimized according to changing traffic pattern and depending on KPls to decide BSC/RNC NodeB/eNodeB (or similar) Rehomes or network expansion by adding more hardware

Telnet Client: - Telnet Client is induced when a set of commands have to be executed on the Network Node after proper authorizations are provided by touch screen or otherwise to modify network elements

Knowledge Base

Engines update the database regularly for audit information, traffic statistics and critical alarms. Audit consists of snap shot of the network, which includes its connectivity within each network element and their general information like used ports status.

Capacity utilization is computed as Traffic carried by each network element to used ports and total avai lable ports. This ratio is used to maximize capacity requirement of a system. Performance, utilization, call flow, signaling is analyzed on real time basis. For example a significant drop in ASR (Answer to seizure ratio) signifies a potential problem. This problem can be analyzed by extrapolating data to find the source of the problem which can be identified as loss of transport facilities, glare issues, failures in handover, hardware issues, congestion on signaling or trunking or IP packet congestions or any other.

Statistics for handover failures, call collision like glare, paging, packet congestions, packets drop, transmission delay, jitter, incorrect routing, and processor (server or network element) load is computed and illustrated in graphical form with possible failure scenario.

Processing of Knowledge Based Data Leads to Decisions

Decisions are primarily based to improve performance or expansion needs to make the network self healing and self optimizing. Decisions are based on results obtained by applying the correlation mechanism to the triggers.

Correlation mechanism basically refers to mechanism where each time a trigger is generated (like increase in call drops or capacity usage at an element going above thresholds) which needs a resolution, this mechanism would make reference to a historical data for all the triggers in the past and would try to correlate this to something in the past, based on the classification and other correlation parameters defined within the system itself. For example, if there is increase in dropped calls at a particular sector (which would be trigger), then the system using correlation would match this situation to a past situation where the correlation parameters (like in this case would be: number of radios, handover parameters, environment of the site, reuse change, general traffic stats like layer 3 messages etc) would match the most with all in its database and come-up with a co-relation factor. At that point system already knows the solutions applied to earlier triggers, thus this time for the most part; depending on how much the co-relation is (basically what the correlation factor is) options for solution would already be there. Hence this would be "pick up an option case ^" rather "dig-up and resolve case". Thus this mechanism greatly reduces the "time to resolve a trigger ^" , thus making the overall network much more robust, stable and most importantly efficient. Also, more we use this mechanism, larger the database for co-relation, thus the system would continue to improve the "time to resolve". Additionally, this saves a lot of human effort and thus benefits the organization.

The way it is implemented in SDAOTN is, at each element, we first define the environment (or parameters) which could be used to compare against different elements in the same classification. Also, thresholds for PIs at each element are defined for generating the triggers. At all times, SDAOTN, keeps log of all the changes in the network (both internal and external), which would we used to take a snap shot of the network for both before and after a trigger is generated. Using these snapshots as inputs, co-relation mechanism would run its analysis and present the user with the best possible solutions. At which point human interference is need into the system just to sign off on the suggested resolution to the trigger. Since most of the analysis would be done by the system in advance, reducing time spend by human intervention to minimum productivity of the organization is increased many folds. Expansion Needs

Results based on changing traffic scenario, utilization of resources, minimum cost routing of traffic may generate requirement of augments of trunking or bandwidth on the backhaul , addition of Radios or Channels on BTS NodeB/RAN (Radio access network).. If more Radios cannot be added new BSC (Base Station Controllers) /RNC /Gateways incase of IP networks, are recommended, similarly more MSC or MSS or other service connectivity gateway s/servers, are recommended in case more BSCs cannot be added. BSC is based on criteria of low cost routing and minimum transport requirements. Manual intervention is also allowed amongst recommendation at this stage to alter plans for RF (Radio Frequency) boundaries - which governs area of propagation of a BSC.

Location based billing combined with LERG will provide optimum routing to the network. In case new trunk or connectivity in form of trunks/channels or I P Traffic (with external world) is added and unlocked optimum routing shall take into effect these changes and start routing calls accordingly. In case there is TDM call failures or increased Packets drop on that particular trunk or path, automatic fallback is executed as the choice and general notification is sent to the administrator.

All the need for additional hardware for expansion shall be computed based on percentage increase of traffic (TDM or packet) based on previous data and present rate of increase. The requirements computed shall be based on one year or six months (or shorter periods as per demand from the telecom operator) build ahead and subsequent Capital Cost shall be calculated.

Performance Needs Performance needs are based on statistics collected from other Network elements.

Handover issues can be attributed to congestion, data-base mismatch, un-optimized parameters, loss of coverage, localized issues, hardware failure or other issues and suggestions shall be provided based on like-hood of causes.

Since typical network is so huge and even i f switching interface generate alarms, these alarms largely go un-noticed till the issue becomes critical. The actions performed by the system will be pro-active and shall act be a "Watch Dog" of the network. Statistics are being collected by various systems and analyses real time / small delay. As soon as the performance degrades, alternatives are created and executed according to following laid out principle.

• Hardware/Software related localized errors for particular NSS/BSS RNC/Routers/Gateways. In case such localized problem happens, traffic is re-routed to avoid the effected network element and minimize the degradation of the network. When the system recovers, the traffic is re-routed to the system again. The operator is only informed of the downtime of the element, so that he can focus on troubleshooting the hardware.

• Problem with Trunks/routers or gateways (TDM or IP traffic): - If fallback trunk choices or routers are not available or overflow is blocking, alternative call routing plan is executed.

• Self analysis and error resolution on issues with location updates, handovers, signaling utilizations, transmission error reports, call quality, ASR's, glare, jitters, delay.

• Logs of changes to the network elements with respect to hardware, software, firmware or environmental ( like changes to neighbor list, RF interference, or radio count etc) are taken into account when creating the "action plan" or script to mitigate both on a short term as well as long term fixes.

• "Action plan" is generated bases on intell igence added to the system from various correlation models, traffic modeling, studied over past "action plans" - this makes the system more robust and stable and adaptable.

Execution

Execution is guided by decisions or "add-hoc" network changes.

After decision is taken the system can execute changes on its own or with human intervention. Scheduling the changes in the network shall remain in the hands of "human". The changes are executed by executing the scripts generated through Telnet Client. The system will be able to execute changes in the network which are expansion or performance driven. Performance driven functions shall be prioritized over expansion driven decisions, though performance related tasks can be related to expansion driven decisions. In case something critically fails, the system shall suggest ways and execute changes so as to minimize the effect of "down-time" or "critical system failures", such as routing changes, transport changes etc.

It involves building of scripts and automatic executions during maintenance window.

Monitor and Revert Back

In case changes introduced produce KPIs which results in degradation of the system fall back procedure is initiated and all the changes are undone. All times KPIs are analyzed for performance of the systems. This invention can be used in Telecom field to optimize the network, build or expand the network, manage the network, remove deficiencies in the network. Use of the invention is to reduce human errors, reduce human effort to sustain and improve telecom network. It can also be used for optimal usage of the network, rate products of different vendors since all of them shall be operated under the same guidelines and principle which now is a variable factor since human effort is being utilized.

The system / software automates the whole process within a telecom network and improves efficiency in running a Telecom services.

Here are various scenarios where this system brings up efficiency:

Scenario / :- Trunk TDM Channels or Virtual circuits for packet data builds looking at traffic utilization.

The concept of today's telecom world is to have planning group looking at Traffic to forecast trunk requirements. "Transport design team "provides mapping of a circuit path from A&Z side and then switch tech turn up the trunks. Some tools have been created to trigger alarms when trunk utilization touches a threshold but after that it is all manual work.

Difference with SDAOTN

Since the system is getting all stats report, when engine processes the information it creates a list of trunk which are utilized above a generally agreed benchmark. It extrapolates looking at historic data to predict trunk/VOIP/IP/ATM traffic requirements for 3 months / 6 months build ahead according to preset conditions.

"Auto Mapping" process kicks in to generate the trunk paths / Mappings or new Routing table in case of IP networks and "hold them" till the process is completed. At this stage a mail is send to user and a Work Order is created informing that trunks are ready to turn up pending confirmation. Once a proper authorization is provided system builds a script for traditional circuit switching or total IP solution and loads into the switch (packet or core). DACS (or MPLS equivalent for IP Network) cross-connects are built and trunks turned up automatically. This saves a lot of effort spend now, long hours to build trunks and maintain.

Difference is that "No Tool" has capability to follow this methodology or process to look at traffic extrapolate requirements with correlation , does mapping and build scripts across all vendor platforms and on available technologies, lessening the work load for day to day activities. What now takes 2-3 weeks for trunking to be completed now takes 10- 1 5 minutes and no one has to look in the traffic report manually to issue Work orders to do augments. No human error on missing some Trunk groups and resulting in congestion.

Scenario 2:- Budgeting

Budgeting, port calculations, hardware needs vary from person to person depending on his background.

Difference with SDAOTN

Since SDAOTN looks at port utilization, Transport facility for port mapping. It proposes budgeting for Transport facilities, switches, DACS. BTS, BSS or analogous elements in IP Network (NSS, RNC, MPLS, RSP, Node B's) every quarter or year basis after it has sufficient data to extrapolate. No system can do that as of today. It also looks at traffic a switch can take and compare it with actual rate of traffic increment and proposes whether a switch expansion is more cost effective or a new switch looking at costing, effort involve, budgeting and look ahead margins.

After SDAOTN provides a budget for a Quarter and it is found that money allocated is less than what SDAOTN proposes, SDAOTN can make required adjustments prioritizing work.

Scenario 3:-

Since budgeting and augments are all done manually, a new network element is also planned manually.

Difference with SDAOTN

By forecasting budget /new network elements. SDAOTN proposed a "power up" date. It also provides a traffic plan for BSC/RNC Re-home or code cuts if it is a GMSC. Once a new network element is "powered up" and SDAOTN is made aware of it all Data Translation including B-Number translation, trunking (VOIP/IP/ATM/TDM), call translations, and mobility parameters are scripted and loaded in the system.

If a launch of MSC/Gateways/Servers is by Re-home of BSS/Router/Switches), SDAOTN shall launch the system automatically in the night during maintenance window and monitor performance of the system. Any degradation of performance is computed with a root cause. If a fix is physical hardware issues the same is alerted otherwise a solution is executed to correct the problem.

Scenario 4:-

RF plans for BSC/RNC or other Access control elements re-home looking for MSC boundaries for minimum handovers and depending on a load of switching element a BSC Re-home is planned. The concept and requirement for BSS Re-home may vary person to person. Difference with SDAOTN

If a MSC (NSS) reaches its capacity limit or a new BSC/RNC is to be added to the Network, BSC/RNC Re-homes is planned with all scripting for SS7/AAL3/AAL5, A- links or Virtual circuits, Handover changes etc. for optimization of the network.

Once proper authorization is provided various processes kicks in like "Auto mapping" and "Auto Trunking" and Auto-Rerouting and "Mobility function" and Re- home is completed during maintenance window without any human effort.

Scenario 5:-

In case PI goes down fault analysis is done manually to narrow down the problem.

Difference with SDAOTN

System is monitoring all the PIs; any degraded performance is evaluated similar to finger printing technique. When ever a problem arises in the network it leaves its mark by a pattern of falling KPIs. These are analyzed to source the problem and a solution is executed which solves the issues. All these actions might happen in couple of minutes, without anyone's noticing that a problem ever occurred. SDAOTN shall provide a "self healing" network which no tool supports.

Invention can be structures in various ways to realize the same out put. Manual interfaces can be built in between various steps for processing

Knowledge Based Data and Executions

The whole project can be split and manual inputs can be employed at every stage to realize the same output.

• Instead of auto trunking which is more efficient, manual trunk builds can be done after auto triggering of alarms of over utilization of the trunk builds.

• Manual drag and drop for BSC / BTS / RNC NodeB or other network elements Re-homes can be planned. • Manual Network element can be added and optimization of network element can be performed again.

• Least cost routing can be performed by manually using data from CDRs. Legs and B - Number analysis on switch.

• Instead of a single platform capable of understanding various other "vendor" switches, multiple platforms can be planned.

• This patent is presently defined for 2G/3G/LTE (4G) Networks with circuit or packet switching core. But it is relevant for future technologies with similar analogies and network elements can be incorporated in this platform with advanced modeling of these elements.

Two processes, "Port Management" and "Script Generation ^"*' , which are intertwined, are used to increase the bandwidth to a destination. Port Management is based on inventory management of existing transport or the capacity which is built in for future growth and Script Generation relies on port management to provide accurate data of available port/transport to create scripts to modify - grow or reduce existing bandwidth.

Port Management

Free ports are computed from audit of switches every day and a "Process Held" process is used to auto-map the ports A&Z side with a redundant transport path including cross-connects. This process can also be initiated manually where select "process held" is used to hold the ports and a mapping spreadsheet is created which is eventually used for trunk builds or to increase bandwidth to a particular destination.

FIGS. 2 and 3 are screen prints of two steps in the Port Management process. In FIG. 2 "Process Held" is used to reserve the ports until augments are completed. "Process Unheld" is the reverse to make the ports free after an expansion plan is cancelled.

FIG. 3 shows free ports which are now reserved which can be used for mapping and later modifying the bandwidth to a destination. Export to excel provides an output spreadsheet. Ports are reserved so that the same ports are not part of a planned expansion of two different projects, which is a part of inventory management.

Script Generation

FIGS. 4-8 are screen prints of steps in the Script Generation process, demonstrating how scripts can be generated manually by simply copying and pasting the information rather than uploading a data file, which can have issues of mismatched columns and misaligned data. This process ensures that any such errors are discovered during run time rather than trying to locate inaccurate data.

The manual procedure generates trunk scripts using a spreadsheet generated by a first process as an input. The process involves copy/paste of bulk data as opposed to manual input of data. A script is generated which is sent to the switch to build and unlock trunks. FIG. 4 illustrates uploading the Excel file containing information about ports, cics, segment or path names, which is needed for any TDM trunking circuit. FIG. 5 illustrates copying and pasting of relevant information as per the columns rather than uploading of files, which can result in more inconsistencies. FIG. 6 shows a screenshot where all the information added is shown and any errors in data is pointed out in terms of any ports which have already been used or any data which might have some error . Other relevant information like DPC, Trunk Group information or scripts needed to add or deleting the data is taken as an input. In FIG. 7, a consistency check is performed to ensure data is current and accurate and if any error is found it is located and scripts are generated. Fig. 8 shows a step in which the system connects to the switch and sends the scripts generated to process the desired changes.

Auto-trunking in 2G:-

This module consists of two sub-modules

• Auto Mapping

• Auto Trunking The system automatically gets free ports from the switch and can hold free ports for mappings for an assigned task. The ports which are held cannot be utilized by other people who are doing mappings for other circuits. Hence no there is chance for the same port being used twice. Other mappings rely on offline databases but from this system mapping is done from an online database which refreshes every day, and updates are made on offline data as Xpercom and Granite.

When the auto-trunking feature is enabled looking at traffic from the last 1 5 days, the system will extrapolate the requirements once utilization reaches a preset level, and from there, it has ports on switches A & Z side, also the transport path. Once requirements are finalized mappings is computed and trunks are build without any human interventions.

Auto-trunking in IP/ATM Networks IP Networks

The system will maintain the database for routers, cost information, and hops to reach destination. The history of events is recorded terms of PIs for the routes including any downtime, delay, jitter and other KPIs.

ATM Networks

The database is maintained for all Permanent Virtual Circuits and Nevis with their throughput capacity and connectivity (A side & Z side) details.

While designing an IP/ATM pipe for routing traffic, database details are used to find redundant paths, with optimized utilization and scripts, a routing details package is generated to route the call flow. APPENDIX

Abbreviations Used In This Document

*.CSV: Comma Separated Value format file

*.PDF: Portable Document format file

*.TXT: Text format file

*.XLS: Microsoft Excel Spreadsheet file

2G: Second Generation Wireless Network

3G: Third Generation Wireless Network

4G: Forth Generation Wireless Network

AAL3: ATM Adaptation Layer #3

AAL5: ATM Adaptation Layer #3

ASR - Answer to Seizure Ratio

ATM: Asynchronous Transfer Mode

BSC - Base Station Controller

BSS: Base Station Subsystem

BTS: Base Transceiver Station

CDR - Call Data Record

CGI: Cell Global Identification

DACS: Digital Access and Cross Connect System

DPC: Destination Point Code

eNodeB: 3rd Generation Partnership Program equivalent BTS

FTP: File Transfer Protocol

GIF: Graphics Interchange Format

GIS: Geographic Information System

GMSC: Gateway Mobile Switching Center

HOLAP: Hybrid Online Analytical Processing

IOF - Inter office Facilities

IP: Internet Protocol

JPG: Compressed Image Format

PI - Key Performance Indicator

LERG - The North American numbering plan is available in a data base called the LERG. LTE: Long Term Evolution

MML - Man Machine Language MPLS - Multi Protocol Label Switching

MSC: Mobile Switching Center

MSS: Mobile Switching Server

Node B: UMTS equivalent to the BTS

NSS: Network Switching Subsystem

NSVCI - Network Service Virtual Connection Identifier.

OSS: Operations Support System

PNG: Portable Network Graphics

PVC - Permanent Virtual Circuits

QOS: Quality Of Service

RAN: Radio Access Network

Re-home - Re-parenting of BSS with NSS

RF: Radio Frequency

RNC - Radio Network Controller

SDCCH: Standalone Dedicated Control Channel

SFTP: Secure File Transfer Protocol

SNMP: Simple Network Management Protocol

SS7: Signaling System #7

SSH: Secure Shell

TDM: Time Division Multiplexing

UID: Unique Identity

UMTS: Universal Mobile Telecommunications System UTC: Coordinated Universal Time

VC: Virtual Channel

VOIP: Voice over Internet Protocol