Abstract:
A telecommunications network capacity planning system. The telecommunications network capacity planning system includes a telecommunications network including a telecommunications services provider, subscribers and a network coupling the telecommunications services provider and the subscribers for provisioning of the telecommunications services. A database system is used for collecting and storing data at the user-level associated with provisioning of telecommunication services over the telecommunications network. A processor is coupled to the database system. The processor models the telecommunications network by generating upward projections from the stored user-level data and transforms the modeling of the network to a visual display of capacity information and network parameters for manipulation to evaluate capacity planning scenarios.

Description:
FIELD OF THE INVENTION 
     This disclosure relates in general to modeling telecommunications networks, and more particularly to using data collected from the user level to project upwards to model a telecommunications network. 
     BACKGROUND 
     Capacity planning involves the identification of hardware and software configurations that are best suited to meet the needs of a telecommunications network. Capacity planning requires an understanding of service levels, resource usage, etc. to align capacity requirements with business demands. One of the major goals of capacity planning is to ensure that the business service-level objectives are met. However, multiple services are competing for the same forward and return path spectrum. Thus, in today&#39;s competitive environment, network quality and performance reliability are as important as the breadth of services offered. 
     A data model representing the telecommunications network is often used in management and capacity planning. System planners use a variety of analytical tools, formulas and techniques to implement a capacity planning methodology. For example, some of the issues involved in capacity planning include defining capacity areas, capacity variables and performance models. Models are used to ensure planning decisions are based on sound information. These models are calibrated and validated to ensure that the models accurately reflect the actual operation of the system. Identifying the relationship between Business Metrics of Interest (BMIs) and available system performance metrics is critical to accurate models and forecasts. BMIs represent the real world transactions that drive a business workload&#39;s resource consumption. System planners and network managers base their decisions on the analysis of the model in an attempt to optimized network configurations and plan network evolution. 
     However, there are often competing interests in determining what capacity plan modifications to implement. A difficult, but important, component associated with capacity planning for cable, Internet and other communications companies is determining how much bandwidth is needed. Typically there are three curves involved in determining how much capacity is needed on a given network. 
     The demand curve is almost an asymptotic curve. However, a point may be reached the demand curve goes to infinity. The retail curve focuses on the product being sold to the users in terms of the growth of the service being provided and is generally linear. Somewhere between the retail and demand curve is the user experience curve that illustrates a measure of the user experience. The user experience curve defines, at any point in time, how much capacity is available to keep customers satisfied. The closer capacity approaches the demand line, the better bandwidth is provided to the user. The closer you get to the retail line, the less expensive the service is, but leaves customers feeling less satisfied about the experience. 
     Previously methods for planning capacity requirements focus on access devices and determining how much bandwidth a group of users are consuming. Projections are made regarding how much bandwidth is the group of users looking for to satisfy their downstream consumption and how much bandwidth are users looking for to meet upstream consumption needs. 
     However, these methods are characterized as a top-down view of capacity planning. Necessarily, top-down capacity planning relies on a very macro level. Thus, the fine grain details that are unique to demographics, to age groups, etc. are missed. 
     SUMMARY OF THE INVENTION 
     To overcome the limitations described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, embodiments for predicting network capacity requirements and assigning hardware resources to meet those requirements are disclosed. 
     Rather than take such a top down view of the network capacity world, embodiments described herein reconstruct a bottom up view. Data is collected on users, demographic parameters, speed tiers, application mixes, etc. This data then may be used to reconstruct the consumption down at the user level. From this, bandwidth capacity planning is projected upwards. 
     An embodiment includes a method for planning capacity requirements of a telecommunications network. The method includes collecting data at the user-level associated with provisioning of telecommunication services over a telecommunications network, storing the collected user-level data in a database, modeling a network by generating upward projections from the stored user-level data and transforming the modeling of the network to a visual display of capacity information and network parameters for manipulation to evaluate capacity planning scenarios. 
     In another embodiment, a computer readable medium is provided. The computer readable medium includes executable instructions which, when executed by a processor, provides capacity planning associated with a telecommunications network by collecting data at the user-level associated with provisioning of telecommunication services over a telecommunications network, storing the collected user-level data in a database, modeling a network by generating upward projections from the stored user-level data and transforming the modeling of the network to a visual display of capacity information and network parameters for manipulation to evaluate capacity planning scenarios. 
     In another embodiment, a telecommunications network capacity planning system is provided. The system includes a telecommunications network including a telecommunications services provider, subscribers and a network coupling the telecommunications services provider and the subscribers for provisioning of the telecommunications services. A database system is used for collecting and storing data at the user-level associated with provisioning of telecommunication services over the telecommunications network. A processor is coupled to the database system. The processor models the telecommunications network by generating upward projections from the stored user-level data and transforms the modeling of the network to a visual display of capacity information and network parameters for manipulation to evaluate capacity planning scenarios. 
     These and various other advantages and features of novelty are pointed out with particularity in the claims annexed hereto and form a part hereof. However, for a better understanding of the disclosed embodiments, the advantages, and the objects obtained, reference should be made to the drawings which form a further part hereof, and to accompanying descriptive matter, in which there are illustrated and described specific examples of the disclosed embodiments. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Referring now to the drawings in which like reference numbers represent corresponding parts throughout: 
         FIG. 1  illustrates an embodiment of one format for the nodes combining plan (NCP) data; 
         FIG. 2  is a screen shot showing the sub-count data according to an embodiment of the invention; 
         FIG. 3  is a screen shot showing the household user data according to an embodiment of the invention; 
         FIG. 4  is a screen shot showing the utilization data according to an embodiment of the invention; 
         FIG. 5  is a screen shot showing the utilization data presented in the proper format according to an embodiment of the invention; 
         FIG. 6  illustrates the importation of the parser modules according to an embodiment of the invention; 
         FIG. 7  is a screen shot showing a directory structure according to an embodiment of the invention; 
         FIG. 8  shows a completed NCP file according to an embodiment of the invention; 
         FIG. 9  highlights the fields which must be set according to an embodiment of the invention; 
         FIG. 10  illustrates a screen shot of the Master CMTS data according to an embodiment of the invention; 
         FIG. 11  shows the filtering of a CMTS list to obtain the unique CMTS names; 
         FIG. 12  is a screenshot of the network dashboard according to an embodiment of the invention; 
         FIG. 13  shows an interface for selecting markets according to an embodiment of the invention; 
         FIG. 14  is an interface for upgrading trigger selections according to an embodiment of the invention; 
         FIG. 15  shows an interface for selecting traffic characterization according to an embodiment of the invention; 
         FIG. 16  shows an interface for executing NCP projections and printing NCP projector outputs according to an embodiment of the invention; 
         FIG. 17  shows the setting of market competitive strategy flags according to an embodiment of the invention; 
         FIG. 18  shows the number of lines card slots per chassis that must be set in the specific market input sheet under the ABC equipment configuration section; 
         FIG. 19  illustrates the correct migration setting for the ABC migration according to an embodiment of the invention; 
         FIG. 20  compares the enabling and disabling cir business services according to an embodiment of the invention; 
         FIG. 21  is a screenshot of a table showing speed inputs that may be changed when switching between EON POR and Retail Scenarios according to an embodiment of the invention; 
         FIG. 22  is a screenshot showing cable modem throughput data entries according to an embodiment of the invention; 
         FIG. 23  illustrates the setting for a market with Cap and Grow enabled beginning in 2008 according to an embodiment of the invention; 
         FIG. 24  shows a table containing the configuration inputs for EQAM devices according to an embodiment of the invention; 
         FIG. 25  is an interface for specifying line cards per CMTS Chassis according to an embodiment of the invention; 
         FIG. 26  is an interface for specifying migration options according to an embodiment of the invention; 
         FIG. 27  shows a set of XYZ migration specifications/inputs according to an embodiment of the invention; 
         FIG. 28  shows the migration options; 
         FIG. 29  illustrates an interface for entering the assumptions and key inputs according to an embodiment of the invention; 
         FIG. 30  is a prompt dialog that is activated when the Projector Model is paused according to an embodiment of the invention; 
         FIG. 31  is a worksheet showing the node split equipment cost according to an embodiment of the invention; 
         FIG. 32  is a worksheet showing the node split installation cost according to an embodiment of the invention; 
         FIG. 33  illustrates the node decombine equipment cost according to an embodiment of the invention; 
         FIG. 34  illustrates the node decombine installation cost according to an embodiment of the invention; 
         FIG. 35  illustrates the interface for updating sales tax according to an embodiment of the invention; 
         FIG. 36  illustrates the interface for disabling the sales tax according to an embodiment of the invention; 
         FIG. 37  is an interface for updating shipping and handling cost according to an embodiment of the invention; 
         FIG. 38  shows the disabling of shipping and handling cost according to an embodiment of the invention; 
         FIG. 39  shows a worksheet for updating CMTS and blade equipment cost according to an embodiment of the invention; 
         FIG. 40  shows a worksheet for updating equipment cost according to an embodiment of the invention; 
         FIG. 41  shows a network share table according to an embodiment of the invention; 
         FIG. 42  illustrates the capital expenditure by year and by major category according to an embodiment of the invention; 
         FIG. 43  illustrates the capital expenditure and budget variance by year and by major category according to an embodiment of the invention; 
         FIG. 44  shows the total capital expenditure by market according to an embodiment of the invention; 
         FIG. 45  shows the node split expenditure by market according to an embodiment of the invention; 
         FIG. 46  shows the CMTS capital expenditure by market according to an embodiment of the invention; 
         FIG. 47  shows the network capital expenditure summary according to an embodiment of the invention; 
         FIG. 48  shows the node split budget variance by market according to an embodiment of the invention; 
         FIG. 49  shows the CMTS budget variance by market according to an embodiment of the invention; 
         FIG. 50  shows the total budget variance by market according to an embodiment of the invention; 
         FIG. 51  shows a report for equipment forecasts according to an embodiment of the invention; 
         FIG. 52  is a report on long range planning projections or managing the overall system according to an embodiment of the invention; 
         FIG. 53  is a flow chart of the overall process flow for the projector model according to an embodiment of the invention; 
         FIG. 54  shows the selected markets desired for the projector model according to an embodiment of the invention; 
         FIG. 55  shows the XYZ processing according to an embodiment of the invention; 
         FIG. 56  illustrates the ABC processing according to an embodiment of the invention; 
         FIG. 57  is a flow chart of the process vendor DS topology; 
         FIG. 58  is a flow chart showing the DS service group optimization; and 
         FIG. 59  is a block diagram of a system  5900  according to an embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments of the present invention are directed to using data collected from the user level to project upwards to model a telecommunications network. 
     Rather than take such a top down view of the network capacity world, embodiments described herein reconstruct a bottom up view. Data is collected at the user-level. The user-level data may include subscriber data, demographic parameters, speed tiers, and application mixes, etc. This data then may be used to reconstruct the consumption down at the user level. From this, bandwidth capacity planning is projected upwards. For example, how much bandwidth each individual user would consume is gathered and then a model is built to move upwards and determine how much capacity is needed for a particular fiber node. Capacity for a group of fiber nodes, e.g., a service group, is determined using the data associated with particular fiber nodes. This process then continues up to an interface on an access device, a particular access device, and thereon through to the network. Accordingly, a determination of how much actual bandwidth consumption is subscribers using, whether on an application basis, on a group, on granular basis such as protocols or even on a fiber cable. 
     Once these calculations have been made, by looking back at hysteresis and going backwards in time and then projecting forward, the compound annual growth rate may be determined. The compound annual growth rate may be used to make projections based on what is currently known. This model may be applied to the application usage, to the overall usage, to whatever specific portion of that consumption is of interest. By pushing this analysis forward, projections may be made further out in time what the actual demand will be so that the plant is not overbuilt unless so desired. If overbuilding the plant is desired, the model allows planners to move the end of the line more towards the consumption side, i.e., the demand curve. 
     Planners may also decide to move the line more towards the retail curve so that an understanding of what that impact of such a move would be on user experience, e.g., what will be the impact on the number of customer trouble tickets that are generated. Moreover, actually knowledge of vendor hardware may be used to assign hardware and cause actions to occur accordingly, e.g., node splits, etc. 
       FIG. 1  illustrates an embodiment of one format for the nodes combining plan (NCP) data  100 . Multiple strands of fiber are provided to a node, e.g., typically in a Dense Wave Division Multiplexing (DWDM) or Coarse Wave Division Multiplexing (CWDM) type configuration which uses multiple local area networks (LANS) such as one for voice, one for data, one for video, etc. The nodes feed back to the head end. The head end feeds to various pieces of access equipment. One such type of access equipment may be a cable node termination system (CNTS). The logic herein works the same regardless of the type of network. The nodes combining plan (NCP) will provide the fiber node name, etc. 
     The NCP parsing process includes three steps. The first step combines the NCP data with the utilization, sub-count and HHP information. The second step augments this information with equipment configuration flags. The equipment configuration flags provide information on the number and source of channels available to the different service groups. The third step incorporates this parsed and processed NCP to provide a capacity projection. 
     During the first step, data is stored in a storage device in a predetermined format. The table shown in  FIG. 1  includes Market Name, Node Name, CMTS Device Name, Slot/Card, Downstream Port, and Upstream port information to describe the current network topology. In  FIG. 1 , the market shown is Lafayette, La. The fiber node name is LC007, which may be shown a node map thereby identifying the particular service area, what street, how many houses, etc. The CNTS includes a card that communicates with the downstream and upstream ports. 
     The data is load into this is the actual utilization for the fiber nodes. Various parameters are monitored, e.g., how much bandwidth users are consuming, how much upstream and downstream bandwidth is being consumed, etc. 
     The NCP file may not contain any NULL rows; NULL rows are those that have no node names associated with them. The NCP file may also be sorted according to device name, slot/card#, DS port and upstream port. 
       FIG. 2  is a screen shot showing the sub-count data  200  according to an embodiment of the invention. In  FIG. 2 , the sub-count data is shown available in two columns. Column A contains the node name and Column B the sub-count. The number of actual subscribers on each physical node may then be determined. 
       FIG. 3  is a screen shot  300  showing the household user data according to an embodiment of the invention. In  FIG. 3 , the households passed (HHP) data is provided with the node-name in column B and the HHP count in column D. 
     Next,  FIG. 4  is a screen shot  400  showing the utilization data according to an embodiment of the invention. In  FIG. 4 , the utilization data is pulled from other sources, e.g., other tools. The utilization data is presented in a predetermined format, wherein the data is entered first in column A, i.e., Column A should not be blank.  FIG. 4  shows a blank column A which will cause the parser to fail. 
       FIG. 5  is a screen shot  500  showing the utilization data presented in the proper format according to an embodiment of the invention. Once all of the data has been loaded, the data is parsed using parser modules. The importing of the parser modules will be discussed below. 
     Once all the required data is available, a base file for each market needs to be created. The base file aggregates the utilization, sub-count and HHP data into one area, e.g., a workbook. The base file may be created by first creating a new spreadsheet and name it using the naming format “MarketName_base.xls,” e.g., “Tucson_Base.xls.” The HHP data is copied into a new area in the base file and it is named “HHP.” The sub-count data is copied into a new area in the base file and named the “sub-count.” The 10-day and 12-hour utilization data is copied into their own areas. 
       FIG. 6  illustrates the importation of the parser modules  600  according to an embodiment of the invention. The parser code is imported into the areas by engaging the Visual Basic (VB) editor, navigating from Go to File to Import File as shown in  FIG. 6 . The module files are selected and “Open” is selected. The user returns to the base file and selects the 10-day utilization tab. The user goes to the VB Editor and selects Module  2  from the selection pane on the left. The user then goes to the “read_utilization” function and runs the parser code of Module  1  using the toolbar. The user returns to the base file, selects the 12-hour utilization tab, and repeats the previous steps. Two new worksheets are generated. The two new worksheets are names such that the naming ends in “-PROCESSED.” These worksheets contain the processed utilization data. The original data is deleted and the new sheets are renamed to “10 day” and “12 hr” respectively. At this point, 4 tabs are available: HHP, Sub-count, 10 day and 12 hr in your base file. The base file is now ready. The user saves the file. Depending upon the market, additional or fewer steps may be necessary. 
     The NCP data for each market may be spread over multiple excel workbooks or contained within a single workbook. However, each workbook/file may only have one tab with NCP data. It is recommended that all the NCP be data be combined into one NCP file to save processing steps and time. 
     To prepare the NCP file, the following steps are executed. For each NCP file, if the data is spread over multiple worksheets, the NCP data is consolidated into one worksheet. All the other sheets are deleted and the lone sheet in the file(s) is renamed to “DOCSIS” The files are saved and closed. 
     The parser requires a predetermined directory structure. To setup the directory structure, a directory for each market is created. The base file for the market, created earlier as described above, is placed in this directory. A folder named “ncp” is created in the same directory and all the NCP files processed earlier are copied into the “ncp” directory. 
       FIG. 7  is a screen shot  700  showing a directory structure according to an embodiment of the invention. In  FIG. 7 , Orange County, for example, is shown. The base file is in the market directory and the NCP files are in the “ncp” directory. 
     The parser is now ready to process the NCP. The parser is executed by opening the base file and launching the VB editor. Module  2  is selected and the user navigates to the “Main” function. The code is run, for example, by selecting a command from the toolbar. The parser will run for several seconds and then stop. The NCP files will be augmented with all the worksheets from the base file and also include two new worksheets named “DOCSIS-DS-Processed” and “DOCSIS-US-Processed.” The former worksheet contains all the downstream information whereas the latter worksheet contains the upstream information. 
     To complete the first step of the NCP parsing process, the user completes the post processing. Here, the user should verify that there are no errors in both the upstream and the downstream processed tabs. If there are any errors in the sub-count, utilization or HHP columns, the values may be replaced with average values for the market. This process will have to be performed manually. Column D still needs to be populated for both the downstream and upstream worksheets. The user may select the downstream worksheet, launch the VB editor and select Module  1 . Then the user may navigate to the “Calc_Subs_ 2 ” function wherein the function may be run by selecting the “Play” button from the toolbar. The upstream worksheets may be modified similarly. 
       FIG. 8  shows a completed NCP file  800  according to an embodiment of the invention. The NCP file shown in  FIG. 8  is used as the starting point for figuring out how large future bandwidth consumption will be. A service group is a combination of the node name and the cable downstream. This information allows the number of subscribers to be determined. For example, CH0CHR1CNPT01 indicates the make and manufacturer of the CNTS, where it is in Oklahoma, the number of subscribers, i.e., 583 subscribers. Then there are 7 fiber nodes associated with that downstream. This allows a determination of the number of subscribers per fiber node, how many households passed for each of those fiber nodes, their average utilization and the peak utilization to be made. By using these numbers, projections looking forward may be made. 
     For example, when average utilization hits is 50% and peak utilization is 80%, the projections may be reviewed to determine that customers are going to have a bad experience and action needs to be taken. Thus, rather than waiting for the customer to have a bad experience, predictions that look in the future allow action to be made ahead within a predetermined time window. An action on that node may not need to be taken today; however, the model may indicate that an action may have to be taken next year. This allows surgical actions to be used to manage the business. 
     Next, the set-up of the equipment is described. The second half of the database provides information regarding the actual physical hardware that is currently implemented. Equipment configuration flags need to be set in the Master Data DS and Master Data US sheets. The equipment configuration flags indicate the number of channels assigned to a particular service group, as well as the source of the channels (e.g. 5×20 vs. EQAM). Since every service group requires its own set of flags, the intention is that flag setting will be an automated process once a DOCSIS 3.0 NCP format is finalized. 
       FIG. 9  is a table  900  that highlights the fields which must be set according to an embodiment of the invention. Every service group requires a single set of flags. If there are multiple nodes on the service group, flags for Columns K-W should be set for just the first node listed in that service group. Column X (Node Profiles), on the other hand, should be set for every node in a service group. Every node is profiled based on the business subscriber&#39;s penetration and usage. 
     The Primary DS and Primary US fields indicate which channels are being used as the primary downstream and upstream channels. In the context of DOCSIS 2.0, primary channels can only be supplied either by 2×8 line cards, or by 5×20 line cards. If the service group is supplied by a 2×8 line card, both columns should contain the value “0”, otherwise, if the service group is supplied by a 5×20 line card, both columns should contain the value “6”. Once DOCSIS 3.0 is available, and TX32/RX32 cards become part of the 2×8 line card configuration, wherein primary channels can also be supplied by the TX32 and RX32 cards. In such a case, a value of “2” should be inputted in Primary DS, and “3” in Primary US. 
     The DOCSIS 2.0 Fields, 2×8 DS, 2×8 US, 5×20 DS, 5×20 US, can only take on a value of “1”, “4” or “0”. If the service group is supplied by a 2×8 MAC domain, 2×8 DS should contain the value “1”, and 2×8 US the value “4”. 5×20 DS and 5×20 US should both contain the value “0”. If the service group is supplied by a 5×20 MAC domain, 5×20 DS should contain the value “1”, and 5×20 US the value “4”. 2×8 DS and 2×8 US should both contain the value “0”. If the service group is neither interfaced with a 2×8 nor a 5×20 MAC domain, all DOCSIS 2.0 fields should contain the value “0”. 
     The DOCSIS 3.0 Fields, TX32, RX32, MDE240, EQAM, indicate the number of channels supplied to service group from the respective equipment piece. For example, a “3” in the TX32 field, and “2” in the RX32 field, indicates that the service group receives 3 QAMs from a TX32 port, and 2 QAMs from a RX32 port. A value of “0” should be entered if no QAMs are supplied by that particular equipment piece. Note that MDE240 refers specifically to 2×8 modular channels, and EQAM specifically to 5×20 modular channels. 
     Node Profiles Column indicates the profile for each node, and consequently, the amount of bandwidth that must be reserved for each node. Definitions for each profile are shown in the Node Profiles sheet. 
     In the first row, number 5 illustrates one of ten different profiles that may be used. Zero is residential only, no business customers. One is a few, two is more. Number five represents a large amount of business customers with a very heavy business demand. And since business customers pay more, a better experience is preferred. The may require bandwidth to be taken off the top to keep business customers happy. 
     Once the NCPs have been parsed and processed, there remains the final step of incorporating them into the Master Data sheets of the Projector file. If old NCP data already exists in the Projector file for the processed market, a replacement will be required, and is included in the instructions. 
     If old NCP data for the given market exists in Master Data DS and Master Data US sheets, the user will delete those specific rows entirely. The last row of Master Data DS and Master Data US should read EOL across columns A to Z. The user will delete this row as this indicates the end of the NCP entries. Then, the user will paste the parsed and process downstream NCP data starting where the EOL entries were previously located in Master Data DS. Likewise, the user will paste the parsed and processed upstream NCP into Master Data US. As a check the total number of row entries in Master Data DS and Master Data US should be exactly equal. 
     In the row immediately after the last entry in Master Data DS and Master Data US, the user will insert the entry EOL in columns A-Z. 
       FIG. 10  illustrates a screen shot  1000  of the Master CMTS data according to an embodiment of the invention. Referring to the Master CMTS Data of  FIG. 10 , all the CMTS′ in each market should be listed. If CMTS entries already exist for the market being incorporated, these rows should be deleted entirely. 
     The last row of Master CMTS Data should read EOL across columns A to E. The user will delete this row because this indicates the end of the CMTS data. Referring to the newly pasted NCP data in Master Data DS, all Column C items for this market are copied. This includes all CMTS names for the market. The copied items are pasted into a new workbook. The CMTS list  1100  may be filtered to obtain the unique CMTS names as shown in  FIG. 11 . 
     A list of unique entries should now be created. The user will check that the first entry is not repeated twice. The user copies all unique entries created and paste them into Column A starting where the EOL row was previously located. For each newly pasted entry in Column A, the user will enter the market name in Column E. Correct spelling of the market name is critical. On the row immediately after the last entry, the user enters EOL in columns A to E to indicate the end of the CMTS list. The model is now ready to be run with updated NCP data thereby allowing user to quickly analyze different scenarios. Below, several typical scenarios will be described. 
       FIG. 12  is a screenshot of the network dashboard  1200  according to an embodiment of the invention. The primary network dashboard screen  1200  is used to simplify the data. On the left, settings unique to certain markets are indicated. The screens provide the ability to show the proficiency for any given market, i.e., how much of the downstream paths and upstream paths based on the current configuration are available for customer use, what the thresholds are. For example, for 80% of the downstream paths, 50% of the downstream, 80% peak, 50% average, 70% upstream peak, 40% upstream average, the action that needs to be taken may be projected. Thus, for 80% peak, 50% average and 50% average, a predetermined activity is triggered and a sequence of decision points is traversed once the predetermined activity is triggered. 
     More specifically, if there are two fiber nodes and one of those fiber nodes is going to exceed bandwidth capacity and cause a bad customer experience, the two nodes are split apart and additional hardware is added only by points to service the new demand so that extra hardware is not just sitting around. 
     In  FIG. 12 , the dashboard includes an interface showing market settings  1210 , bandwidth offerings  1212  and key equipment configuration inputs  1214 . Another interface  1216  is provided showing a summary of the projector output. On the right side of  FIG. 12 , an interface  1220  is provided for selecting traffic characterization. An interface  1222  is also provided for upgrading trigger selections that cause an event to happen based on the number of subscribers that are predicted to be in that fiber node or that can be supported. Markets that are to be included in the run may be selected using a market selection interface  1224 . NCP projector outputs may be selected for printing  1226 . Also, a selection is provided for executing NCP projections and printing  1228 . 
     Also, the network includes devices called HQAMs, and in these HQAMs a single cable is coming out. The block upconverter stores downstream data coming out of that single port contiguously, e.g., channels  2 ,  3 ,  4  and  5 . However, only channel  2  may currently be in use. Therefore, if an additional downstream path is needed, if one is available and there is frequency available, another downstream path may be implemented so additional capital expense would not be required. However, if another downstream path is not able to be implemented or additional frequency is not available, and then channels would be combined in a node if the node has the capability. If the node could not be de-combined because there was no additional capacity at that point, a node would have to be split, which means service personnel would have to physically go out, lay cable on the ground or in the air, install new hardware, obtain the initial pole rights, verify the right of way, etc. Obviously, this is a very expensive operation. Thus, these physical operations should be minimized as much as possible. The process for the upstream path is a much simpler scenario because additional modulation is available. More speed may be obtained out of the same channel by increasing the modulation. The bandwidth offering is defined by the strategy and project management group and the equipment configuration is dependent on engineering recommendations and what the equipment that each market may have. 
       FIG. 13  shows an interface  1300  for selecting markets according to an embodiment of the invention. The user selects the markets that are to be included in the run from the market selection box. The user selects the capacity upgrade triggering mode in the upgrade triggers box. The key requirements are also listed there. This indicates on a year by year basis how many nodes have to be de-combined, how many splits need to be made, etc. 
       FIG. 14  is an interface  1400  for upgrading trigger selections according to an embodiment of the invention. Upgrade triggers that cause an event to happen may be based on the number of subscribers that are predicted to be in that fiber node or that can be supported. For example, the “Subscriber Count Only” will only consider subscriber counts on each of the service groups when determining capacity upgrade requirements. The Sub.Count OR Measured Utilization will consider both the subscriber counts and downstream/upstream utilizations on each of the service groups. Measured utilization only applies to the first year while subscriber counts apply to all years. 
       FIG. 15  shows an interface  1500  for selecting traffic characterization according to an embodiment of the invention. In the Traffic Characterization box, the user selects the method for projecting cable modem throughputs. For example, modeling may be based on the amount of application being distributed, whether peer to peer traffic, web surfing, file downloading, movies, etc. The “Model with Application Usage Engine” grows cable modem throughput linearly with the growth in application bandwidth requirements, as calculated in the Application Demand tab. 
     The “Compound Growth Rate” grows cable modem throughput by a set percentage year over year. A separate growth percentage can be specified for DS and US. Modeling may also be based on a compound growth rate. You can set the bandwidth for downstream to 38% and the upstream to 28%. Models may be run for different possible scenarios to identify different results. 
     Rating factors may also be used. 
     The “De-rating Factor” grows cable modem throughput in correlation with the growth in the bandwidth offering for that year. Instead of growing throughputs linearly with bandwidth offerings, a de-rating factor can be specified to de-rate the otherwise linear growth. For example, if a user currently has a de-rating factor and has 10 megabits downstream and typically uses 50 kilobits on average, what happens to the user&#39;s consumption when the speed is increased to 20 megabits 
       FIG. 16  shows an interface  1600  for executing NCP projections and printing NCP projector outputs according to an embodiment of the invention. The Print Topology Sheets is selected if projected NCP outputs are required. The Run Model for Selected Markets is selected to run the projector modeling. Once all market input sheets are completed, runs can be performed solely from the Network Dashboard. 
       FIGS. 17-28  illustrate the execution of a plurality of scenarios according to an embodiment of the invention. 
       FIG. 17  is a table  1700  showing the setting of market competitive strategy flags according to an embodiment of the invention. For example, changing a market from Fiber to DSL, or vice versa, requires a change in both the Business Dashboard, and the specific market input sheet. The Business Dashboard contains flags for each of the markets specifying whether it is Fiber or DSL. In  FIG. 17 , a value of “3” is used to specify a market as Fiber or FiOS competitive. Likewise, for DSL markets, a value of “1” is used. 
     Having appropriately set the flag on the Business Dashboard, the Cable Modem Throughput inputs are adjusted on the specific market input sheet. Throughputs need only be changed for the current year, and should be changed to reflect the bandwidth that is offered in the year for that particular market, e.g., see rows  348 - 370 . 
     Various groups may have different ways of adding service groups.  FIG. 18  is a screenshot  1800  of a first type of CMTS chassis according to an embodiment of the invention. The default configuration for the first type of CMTS chassis allows for a total of 35 service groups per chassis. Reducing to 24 service groups per chassis is accomplished by limiting the number of 5×20 line card slots per chassis. Whereas the default configuration for the first type of CMTS chassis accommodates up to 7 5×20 line cards per chassis (7 line cards×5 service groups/line card=35 service groups/chasses), a 24 service group per chassis can be simulated by limiting the number of line cards to 5 per chassis. The number of lines card slots per chassis must be set in the specific market input sheet under the ABC equipment configuration section shown in the screenshot of  FIG. 18 . The highlighted row in  FIG. 18  illustrates the input that needs to be changed. 
     Since a market may have already have CMTS chasses with over 24 service groups, a flag must be set under the Migration Options of the ABC CMTS to force a migration to the new configuration. This is achieved by enabling the Migrate to Different CMTS option, and selecting 2×8 DS from both the drop-down fields. 
     Next, the profile, enabling, disabling, CIR services, etc. are provided in a plan of record. The scenarios may be manipulated and then the utilization per subscriber may be analyzed. 
       FIG. 19  is a screenshot  1900  illustrates the correct migration setting for the ABC migration according to an embodiment of the invention. Changing the line cards per chassis also requires a change in the number of SPA cards per chassis. With a 24 service group per chassis configuration, a SPA card is required for every QAM per EQAM port. This can be configured within the ABC Equipment Parameters section. Technically, limiting the CMTS to 5 line card slots per chassis creates a 25 service group per chassis configuration. 
       FIG. 20  is a comparison  2000  of the enabling and disabling cir business services according to an embodiment of the invention. The Projector Model allows a node-by-node specification of the CIR business services available to that node. Definitions of each profile are provided in the Node Profiles worksheet. The default setup assigns a profile of “0” to nodes that do not possess any business CIR services. As such, disabling CIR business services across all nodes requires setting all nodes to Profile 0. This is accomplished by changing every value in Column X (“Profile”) of Master Data—DS and Master Data—US to 0. Re-running the model will display results for a scenario in which there are no CIR business services. 
       FIG. 21  is a screenshot  2100  of a table showing speed inputs that may be changed when switching between EON POR and Retail Scenarios according to an embodiment of the invention. The Projector Model can switch between EON POR and Retail scenarios by changing only a few inputs. The key difference between the EON and Retail scenarios is the bandwidth speed offerings—as such, the bandwidth offering must be changed in the Business Dashboard. 
     In  FIG. 21 , the tables contain inputs for the Premier, Preferred, Value, Economy and Tier 5 service tiers, and are broken out by downstream and upstream. The first table, labeled Fiber Competitive Strategy, holds the inputs for Fiber markets. Likewise, the last table, labeled DSL Competitive Strategy, contains the inputs for DSL markets. The shaded table in the middle is a placeholder for a third competitive strategy. Changing the bandwidth for a given tier will impact the cable modem throughput to the user. As such, the cable modem throughput inputs must also be updated in Projector. Cable modem throughput inputs are specified on a per market basis in the individual market input sheets under the Utilization Engine Inputs section. Note that throughputs are required for both downstream and upstream for each tier. The inputs are specified for just the first year. Beyond that, throughput growth is correlated with growth in the bandwidth speed offering. 
       FIG. 22  is a screenshot  2200  showing cable modem throughput data entries according to an embodiment of the invention. The entries in  FIG. 22  may be used for enabling and disabling cap and grow. In order to accurately capture market strategies, the Projector Model has the option to cap all XYZ CMTS chasses and increment only ABC CMTS chasses. Despite capping additional XYZ CMTS purchases, all existing XYZ chasses will remain in the topology, and undergo configuration migrations to include TX32, RX32, MDE240 cards, etc. Only at the point where a XYZ chassis is fully populated, will a trigger be enabled to transfer any additional service groups to an ABC chassis. This function is enabled on a market-by-market basis on the specific market input sheet. 
       FIG. 23  is a table  2300  illustrates the setting for a market with Cap and Grow enabled beginning in 2008 according to an embodiment of the invention. The section beginning on Row  630  of the market input sheet contains both the Cap and Grow toggle, as well as a dropdown to specify the year in which the capping is to be enabled. Note, CMTS capping can only be applied to XYZ CMTS chasses. Based on market feedback, no need for ABC capping functionality was required. 
       FIG. 24  shows a table  2400  containing the configuration inputs for EQAM devices according to an embodiment of the invention. The Projector Model has the option to choose between two different EQAM devices—the EQAM  1 , and EQAM  2 . These devices can be used with both ABC and XYZ CMTS chasses. 
     To enable an EQAM device for an ABC CMTS, the appropriate device must be selected from the dropdown on Cell H520 of the specific market input sheet. The two choices are EQAM  1  and EQAM  2 . Once the device is selected, the appropriate fields for the EQAM device must be completed. If EQAM  2  is selected from the drop-down, then only the EQAM  2  inputs are relevant. To add EQAM  2  devices in a particular year, the Availability drop-downs in  FIG. 24  must be changed from N/A to Available. Along with this change, the Maximum Channels per EQAM Port must be changed from 0 to the appropriate value. The assumption is that each CMTS port will be augmented with a single EQAM port, receiving up to the specified number of additional QAMs/channels from the EQAM port. 
     Likewise, if EQAM  1  is selected, only the EQAM  1  inputs in  FIG. 24  are relevant. Given the nature of the EQAM  1 , its availability is specified numerically on Row  529 . A value of 0 specifies that no EQAM  1  devices are available that year. A value of 1 indicates just a single EQAM device per chassis whereas a value of 2 indicates two EQAM devices per CMTS. Since a single EQAM  1  has 18 ports, a single EQAM  1  per CMTS allows for only half of the ABC CMTS ports to receive an augmenting EQAM port. On the other hand, if two EQAM  1  devices per CMTS are selected, all ABC ports will be associated with an EQAM port. As with the EQAM  2  inputs, the Maximum Channels per EQAM Port must also be specified. 
       FIG. 25  is an interface  2500  for specifying line cards per CMTS Chassis according to an embodiment of the invention. For example, in selecting an EQAM device, the appropriate number of SPA cards per CMTS Chassis must be specified. Row  509  in the specific market input sheet contains the inputs for the SPA cards. 
       FIG. 26  is an interface  2600  for specifying migration options according to an embodiment of the invention. For example, the ABC Migration options must be appropriately set. If an EQAM device is available in a particular year, Port Addition  1  must be enabled for that year, with Existing Port set to 5×20 DS, and Augmenting Port set to EQAM. 
     XYZ CMTS chasses have evolved to also support a modular architecture. The EQAM selection steps for XYZ are the same as those outlined for ABC, with the following exceptions. Configurations are set in the XYZ Equipment Parameters section. XYZ CMTS has the concept of MDE240 cards instead of SPA cards. If EQAM devices are available in a particular year, the MDE240 card field should be set to 1 instead of 0. As with ABC, Port Addition  1  must be enabled for years where EQAM devices are available. However, specific to XYZ, Existing Port must be set to TX32, and Augmenting Port must be set to MDE240. 
     In order to run a DOCSIS 2.0 only scenario, all DOCSIS 3.0 equipment inputs must be zeroed or disabled for all years in the specific market input sheet. This includes the following line items: 
     SPA Cards per Chassis 
     Usable TX32 Line Cards per Chassis 
     Usable RX32 Line Cards per Chassis 
     Usable MDE240 Cards per Chassis 
     As such, Usable 2×8 Line Cards per Chassis in the XYZ section must remain at 11. In addition, all toggles in the Migration Options must be set to Disabled. The only exception is the case in which there is a migration from 35 to 24 service groups per chassis as described above. 
       FIG. 27  shows a set of XYZ migration specifications/inputs  2700  according to an embodiment of the invention. Whereas ABC migration options are only used for the two scenarios, as outlined above, XYZ markets require a greater number of migration specifications given the devices&#39; integrated nature. 
       FIG. 28  shows the migration options  2800  for the XYZ device according to an embodiment of the invention. In  FIG. 28 , there is no DOCSIS 3.0 available in 2008, and as such there are 11 2×8 available line card slots specified in the inputs, with all other DOCSIS 3.0 items zeroed. In 2009, the number of 2×8 line cards reduces to 8 available to accommodate for 2 TX32 blades able of providing up to 2 channels per port. In moving from 11 to 8 line cards per CMTS, some service groups may need to be transferred to another CMTS. In order to capture this, Migrate to different CMTS in Migration Options must be set to Enabled, with Migrating Port set to 2×8 DS, and only migrate if SG does not contain: set to TX32. With this setting, a service group will not be migrated to another CMTS if it is already coupled with a TX32 port. Since TX32 blades are now available, they can be coupled with the 2×8 ports to provide additional channels and DOCSIS 3.0. This coupling is toggled by setting Port Addition  1  to Enabled, with Existing Port set to 2×8 DS, and Augmenting Port set to TX32. 
     In 2010, TX32 blades and RX32 blades are increased to 4 of each type per CMTS. With the availability of RX32 blades, TX32 channels can act as primary channels with there being no need for 2×8 channels. As such, the input for Available 2×8 Line Card slots has been zeroed for 2010. All these changes are captured by the five Migration Options specified in 2010. The Options are followed in a sequential manner from top to bottom. As in 2009, Migrate to Different CMTS must be enabled to accommodate for 2×8 ports that may be stranded as a result of the reduction in the available line card slots. Also as in 2009, Port Addition  1  must be enabled to couple TX32 ports with 2×8 ports. Port Addition  2  must also be set enabled, with Existing Port set to TX32, and Augmenting Port set to RX32. This couples the RX32 upstream ports with the TX32 downstream ports. With the availability of RX32&#39;s, there is no need for 2×8 ports to act as primaries. To capture this, Primary Port Change must be enabled, with “If contains:” set to RX32, “New Primary” set to TX32, and “Old Primary” set to 2×8 DS. The final step is the removal of the 2×8 ports from the service groups altogether, such that the service groups are interfaced to just TX32 and RX32 ports. This is accomplished by enabling Migrate All Legacies, and setting Migrate From: to 2×8 DS, Migrate to (Downstream): to TX32, and Migrate from (Upstream): to RX32. At this point a complete migration of all service groups to TX32&#39;s and RX32&#39;s has occurred. 
     In 2011, none of the migration options apply and are thus all disabled. In 2012, EQAM devices are introduced through the MDE240. These MDE240 ports will augment the existing primary TX32 ports. This is initiated by enabling Port Addition  1 , and setting Existing Port to TX32, and Augmenting Port to MDE240. In 2013, EQAM devices are still available and hence, the migration specifications from 2012 are repeated. 
     The XYZ scenario described above is typical of XYZ markets, and is based on commercial availability of the equipment and software release plans. The scenario depicts an introduction of DOCSIS 3.0 in 2009. Pushing DOCSIS 3.0 forward to 2008 requires only that the migration options and configurations for 2008 be set to those for 2009—the only exception is that there will typically be 1 TX32 per CMTS, with just single channel per TX32 port in 2008. 
       FIG. 29  illustrates an interface  2900  for entering the assumptions and key inputs according to an embodiment of the invention. In  FIG. 29 , the year may be started based on the data. The Projector Model has a rolling six year projection window. The Projector Model is thus able to project until then end of 2013 in 2008, to project until the end of 2014 in 2009 and so forth. Updating this start year, and hence the projection window, requires that the Start Year (Cell C 9 ) in the Assumptions and Key Inputs interface to be set to the appropriate start year. In addition, all inputs are updated to reflect the new time window. 
     For the annual refresh, ALL Projector inputs need to be refreshed as applicable. The following list provides a checklist of items that require a refresh:
         LRP subscriber data (see section 5)   Financial Inputs including pricing for equipment, node split costs, decombine costs, sales tax and shipping and handling costs (See Section 3)   Node profile data   All market-specific inputs on the market input sheets   Take rates   Bandwidth and market offering on the business dashboard   NCP data for the markets   Budget data       

     The Projector Model also contains modulation order inputs for each of the four upstream ports. Modulation orders are specified on a market-by-market basis—as such, changes to the modulation order inputs occur on the specific market input sheet and are available as drop-down boxes on Rows  421 - 424 . 
       FIG. 30  is a prompt dialog  3000  that is activated when the Projector Model is paused according to an embodiment of the invention. Since a run may take between 20 to 30 minutes, it may at times be necessary to halt Projector Model in the middle of a run. To manually halt the Projector Model, the user clicks on Excel in the taskbar and press CTRL+Pause. This will pause the Projector Model and initiate the prompt shown in  FIG. 30 . Pressing Continue will continue the run from this paused state. End, on the other hand, will end the run all together with no option to continue the run afterwards. 
     The financial data includes information concerning the network costs and configurations. Thus, after the model is run, a projection of how much bandwidth that any fiber node needs is generated. Therefore, the modeling will determine not only the hardware that is necessary to provide a particular level of service, but also the cost of that hardware is projected from the bottom up. Then, sales tax, shipping and handling, installation costs, etc. are accounted for. 
     All Projector financial inputs are on the NTK CONFIG and COSTS sheet and the Assumptions sheet. Only these two sheets should be changed. The Projector Model defines two major categories of costs: (1) market-independent costs and (2) market-dependent costs. As the names suggest, market-independent costs are uniform across all markets and include costs such as Shipping and Handling Cost, Decombine cost, Sales Tax, and CPE costs. Node Split costs were initially treated as independent costs but can now be customized on a market-level. 
     To update any cost, the relevant row on the NTK CONFIG and COSTS sheet is located and the cell&#39;s value is changed to reflect the correct cost. The key worksheets that constitute the financial engine of the Projector Model include the input sheets and output sheets. For the input sheets, NTK CONFIG and COSTS contains all costs required to forecast the capital expenditure once Projector has output the equipment forecast. Assumptions include start year, active markets for the current Projector run, and EON budget data to drive various results reported by the Projector Module. To update budget numbers, the EON CAPEX BUDGET view section should be updated. This will be described below. 
     For output sheets, Financial Detail combines the costs form the NTK CONFIG and COSTS sheet as well as the projector equipment forecast to output the total costs on a market level. The Financial Summary rolls-up the costs from the Financial Detail sheet and reports it at higher level. There are several views available on this sheet: Network Capital Expenditure Summary by Equipment, Total Capital Expenditure (Node Split and CMTS), Total Capital Expenditure By Market, Total Node Split Capital Expenditure By Market, Total CMTS Capital Expenditure by Market and the Network Equipment Forecast summary. 
       FIG. 31  is a worksheet  3100  showing the node split equipment cost according to an embodiment of the invention. Market node split equipment (capital expense) costs can be updated by changing the values on the input table on the NTK CONFIG and COSTS worksheet starting on row  14 . Currently, the equipment costs remain the same year over year but this constraint is not enforced by the model. 
       FIG. 32  is a worksheet  3200  showing the node split installation cost according to an embodiment of the invention. Market node split installation (operating expense) costs can be updated by changing the values in the cost table on the NTK CONFIG and COSTS worksheet starting on row  57 . Currently, the installation costs remain the same year over year but this constraint is not enforced by the model. 
       FIG. 33  illustrates the node decombine equipment cost  3300  according to an embodiment of the invention.  FIG. 34  illustrates the node decombine installation cost  3400  according to an embodiment of the invention. The node decombine cost can be changed by updating cells C 44  and C 87  on the NTK COFIG and COSTS worksheet. C 44  reflects the cost of equipment and C 87 , the cost of installation. 
       FIG. 35  illustrates the interface  3500  for updating sales tax according to an embodiment of the invention. The sales tax rate can be updated by changing the value on cell C 101 .  FIG. 36  illustrates the interface  3600  for disabling the sales tax according to an embodiment of the invention. Sales Tax can be discounted from the financial calculations by changing the value on cell D 101  to ‘0’. Enabling the sales tax calculation is as simple as changing the value of cell D 101  to ‘1’. A value of ‘0’ will show up as a “No” in the cell whereas a value of ‘1’ will show up as a “Yes.” 
       FIG. 37  is an interface  3700  for updating shipping cost according to an embodiment of the invention. The CMTS and Blade shipping and handling costs can be updated by changing the value on cells C 96  and C 97 . 
       FIG. 38  shows the disabling of shipping and handling cost  3800  according to an embodiment of the invention. The shipping and handling cost can be disabled and discounted from the financial calculations by changing the values on cells D 96  and D 97 . To disable calculations, change the value of the cells to ‘0’. To enable the costs, change the value back to ‘1’. A value of ‘0’ will show up as a “No” in the cell whereas a value of ‘1’ will show up as a “Yes.” 
       FIG. 39  shows a worksheet  3900  for updating CMTS and blade equipment cost according to an embodiment of the invention. The actual configuration, which is a per market configuration thereby allowing every market to be unique, is used. 
     In  FIG. 39 , a configuration is generated for a particular node or a particular market. Rather than using a top down approach, prior planners use a blended average looking at a full populated access device of 250,000 nodes. Ten line cards provide services to customers. Therefore, an estimate of $25,000 a line card would be used. If ten are available, a whole chassis may be folded up even though there is other equipment in the node. When no additional line cards could be fitted in the node, the node would have to be split or additional hardware would be needed. If the node grew beyond a certain count, additional hardware was added. 
     However, the projector model provides knowledge concerning how many actual subscribers there are, how many homes are passed, consumption usage is projected going forward rather than guessing at it and waiting for it to actually happen before an action is taken. 
     So instead of having extra capacity that is not being used, or instead of waiting until an action is required, the projections allows services to be planned and equipment ordered ahead of time without a significant period of the equipment just sitting around. 
     Each market has costs broken down by CMTS and blade as well as by the two major vendors, ABC and XYZ. If additional items need to be added to the CMTS chassis, they need to be added to the CMTS configuration section. Adding an item in the configuration section will automatically populate the item in the costs section. For example, in  FIG. 38 , there is 1 redundant TX-32 card in each XYZ BSR configuration. This number remains constant through all the years but the model allows the numbers to be changed year over year. ABC 10K configurations can be updated in a similar manner. 
       FIG. 40  shows a worksheet  4000  for updating equipment cost according to an embodiment of the invention. The costs of each of the components listed in the configuration can be updated by changing the values accordingly. Currently, most markets follow a standard discount off of the list price to calculate the cost of the component. However, costs can be updated on a case-by-case basis by updating the value in the relevant cell. In  FIG. 40 , the cost for a subset of the components for a particular market is shown. While the model currently keeps the costs constant year over year, this is not a requirement and costs can be changed as needed. 
     Budget numbers are used to report the variance of the Projector forecasts from the EON budget. All budget numbers can be found on the Assumptions worksheet. There are three major sections that correspond to budget information, namely, overall budget by year, year-to-date actual spend and effective budget. These sections can be found starting on row  30  of the Assumptions worksheet. 
     The overall budget by year includes the actual budget over the entire time horizon and should, in theory, remain constant. The actual spend by market by year section reflects the money already spent and should be updated as updated numbers become available. The effective budget by year section reflects the remaining or effective budget by year and is a difference of the overall budget and the actual spend. Certain markets, such as Phoenix and Tucson, may be reported as a bundle. For these markets, the network share between markets table on the Assumptions page contains the percentage share for the individual markets in the bundle. 
       FIG. 41  shows a network share table  4100  according to an embodiment of the invention. The percentages are used to calculate the individual markets that are parts of bigger bundles. The first column identifies the market, the second column is the share of total households passed (HHP) and the third column is the share for a network group. Therefore an 86.6% share for Phoenix means that Phoenix contains 86.6% of all the homes passed in the combined Phoenix and Tucson markets. 
     The Projector Model has been formatted so that key equipment and financial formats can be reported easily. Most financial reports can be found on the “Financial Summary” worksheet. There are a few different options for reporting forecasted capital expenditure depending on the level of granularity required. 
       FIG. 42  illustrates a table  4200  showing the capital expenditure by year and by major category according to an embodiment of the invention. At the highest level, the Financial Summary-PPT worksheet table breaks out the total forecast Capital Expenditure by year into the two major cost buckets: (1) Node Split cost and (2) CMTS cost. This break-down of the expenditure follows the EON budget model. This report also shows total yearly variance from the EON budget. 
       FIG. 43  illustrates a table  4300  showing the capital expenditure and budget variance by year and by major category according to an embodiment of the invention. The report shown in  FIG. 43  adds Node Split and CMTS budget variance figures to the report above. 
       FIG. 44  is a table  4400  showing the total capital expenditure by market according to an embodiment of the invention.  FIG. 45  is a table  4500  showing the node split expenditure by market according to an embodiment of the invention.  FIG. 46  is a table  4600  showing the CMTS capital expenditure by market according to an embodiment of the invention. The three market level tables shown in  FIGS. 44-46  report total capital expenditure, node split capital expenditure and CMTS capital expenditure at the market level. All three tables can be found on the Financial Summary worksheet starting at Row  57 . 
       FIG. 47  is a table  4700  showing the network capital expenditure summary according to an embodiment of the invention. The capital expenditure report by network components is the most granular summary table that can be reported. This table can be found on the Financial Summary sheet starting on Row  5 . 
       FIG. 48  is a table  4800  showing the node split budget variance by market according to an embodiment of the invention.  FIG. 49  is a table  4900  showing the CMTS budget variance by market according to an embodiment of the invention.  FIG. 50  is a table  5000  showing the total budget variance by market according to an embodiment of the invention.  FIGS. 48-50  show the incremental and cumulative variances for each market. 
       FIG. 51  is a table  5100  showing a report for equipment forecasts according to an embodiment of the invention. The table summarizing equipment forecasts by year can be found on the Financial Summary worksheet starting on Row  171 . 
       FIG. 52  is a table  5200  showing long range planning projections or managing the overall system according to an embodiment of the invention. The LRP Projections sheet shown in  FIG. 52  contains subscriber information segmented by CHSI, CDT, CBI, and CBT services. The DOCSIS SUBSCRIBERS group sums the subscribers from each of the services. Each segment contains Starting Subscribers, Gross Adds, Monthly Churn Rate, Deactivations and Ending Subscribers. The Projector Model uses the growth rate in subscribers for each market to project the subscribers per node for all nodes in that market. 
     The LRP worksheet takes as inputs the following data:
         Starting Subscribers for each market for the base/start year   Gross Subscriber Additions for each market for all years   Monthly churn for each market for the base/start year   Deactivations for each market for all years   Ending Subscribers for each market for all years       

     The LRP worksheet calculates the starting subscribers, the average subscribers and the monthly churn. The starting subscribers for a given year are equal to the ending subscribers for the previous year. The model takes the first year starting subscriber data as input. The average subscribers are calculated as the average of starting and ending subscribers for a given year. The monthly churn is calculated as the deactivations for the year divided by the average subscribers for the year divided by 12, i.e., the number of months. For years where data is unavailable, the model uses a linear projection using the growth rate from the previous year 
     To update the LRP data, data on the number of starting subscribers, the gross ads, the monthly churn, the number of deactivations and the number of ending subscribers is collected. For starting subscribers, the base year subscriber information for all markets is updated. For gross ads, the data for all markets for all years is updated. For the monthly churn, the base year churn rate for all markets is updated. For deactivations, the data for all markets for all years is updated. For ending subscribers, the data for all markets for all years is updated. 
     The Projector Model according to an embodiment of the invention provides a granular, bottoms-up approach to capacity planning and equipment migration based on several key methodology assumptions. First is capital expenditure minimization. Equipment should be added only on an as-needed basis to minimize equipment costs. The existing base in a head-end should be exhausted before any additional equipment is incremented. Next, the focus is MAC domain level processing. Topologies are analyzed at the MAC Domain level and individual node statistics and subscribers within the MAC Domain are aggregated before processing. 
     Geographical constraints are also considered. Topologies are analyzed within a given head-end. CMTS chasses are incremented only within the same head-end. RF Gateways are shared only with CMTS chasses within the same head-end. As necessary topology upgrading is another key consideration. In line with the as-needed processing approach, the projector model increments equipment only once a capacity/utilization threshold is crossed. The projector model does not add any capacity buffers. 
     The same tier mix should be applied across all nodes in a market. Each node in the market is assumed to have the same tier mix as specified by the tier inputs for that market. For configuration migrations, all changes in equipment configurations occur at the start of the year for which they are specified. Capacity processing only takes place after the configuration change has been made. 
     The optimal packing of CMTS chasses should be implemented. The projector model assumes that all CMTS that are read from the NCP are utilized optimally. This also assumes that the minimum number of line cards was used to support the service groups read in. The methodology also considers the dedicated bandwidth reservation. Bandwidth for CIR services is carved out of a channel&#39;s capacity before maximum allowable subscribers per channel areas calculated. Bandwidth reservations are aggregated to the service group level. Node splitting and de-combining assumptions are also a factor. Node splits are assumed to exactly halve both the subscriber and the homes passed in the parent node. Node de-combines will place the largest node in the newly created service group. 
       FIG. 53  is a flow chart  5300  of the overall process flow for the projector model according to an embodiment of the invention. Process Flows for Projector&#39;s core algorithm are provided. In  FIG. 53 , data points or values are collected  5310  and actions  5320 . Conditional statements  5330  provide logic for modeling the network. XYZ functions  5340  and ABC functions  5350 . Although some examples only show the process for downstream, a very similar algorithm or process applies for upstream. In addition, process flows are not exhaustive of all algorithm functions and operations. Process Flows instead capture the key operations at a high-level. 
       FIG. 54  is a flow chart  5400  showing the projector model for selected markets according to an embodiment of the invention. The variables are initialized and the outputs are cleared  5410 . All inputs and toggles on the dashboard are read  5412 . Each selected market is cycled through  5414 . 
     For market X  5416 , all market X XYZ entries from master data sheets are filtered  5418 . Each of the six years is cycled through  5420 . For year Y  5422 , XYZ processing is performed  5424 . If cap and grow are enabled  5426 , then the process stores “excess” XYZ service groups  5428 . If not  5430 , continue. If Y=6  5432 , then set Y=0  5434 . If Y&lt;6  5436 , then Y=Y+1  5438 . 
     All market X ABC entries from master data sheets are filtered  5440 . Again, the process cycles through each of the six years  5442 . For year Y  5444 , perform ABC processing  5446 . If Y&lt;6  5448 , then Y=Y+1  5450  and loop to ABC processing  5446 . If Y=6  5454 , then set Y=0  5456 . 
     The number of maximum subscriber statistics for all markets is displayed  5458 . The node split and decombine lists are displayed  5460 . The next market is processed  5462  by incrementing X  5464 . 
       FIGS. 55-56  illustrate the flow charts for the ABC and XYZ processing according to an embodiment of the invention. In  FIG. 55 , XYZ processing  5500  will first be described. The first step is to perform all migrations at the beginning of the year  5510 . Then, XYZ DS topology is processed  5512 . The XYZ US topology with DS triggered changes is updated  5514 . The XYZ US topology is processed  5516 . The XYZ DS topology is updated with US triggered changes  5518 . The DS and US XYZ topology sheets  5520  and the XYZ equipment requirements forecast  5522  are printed. 
       FIG. 56  illustrates the ABC processing  5600  according to an embodiment of the invention. For ABC processing, all migrations are performed at the beginning of the year  5610 . ABC DS topology is processed  5612 . Then, “capped” XYZ SGs are transferred to ABC  5614 . The ABC US topology is updated with DS triggered changes  5616 . ABC US topology is processed  5618 . The ABC DS topology is updated with US triggered changes  5620 . The DS and US ABC topology sheets  5622  and the ABC equipment requirements forecast  5624  are printed. 
       FIG. 57  is a flow chart  5700  of the process vendor DS topology. In  FIG. 57 , the migrations for the year are completed  5710 . The variables for DS processing are initialized  5712 . Subscribers are grown on each node using the market growth rate  5714 . Each SG in the master data DS is cycled through  5716 . For service group X  5718 , DS service group optimization is performed  5720 . Each of the six years is cycled through  5722 . 
     If node split decombine is required  5724 , then the equipment requirements are determined  5726 . If no port are available on the CMTS  5728 , the other CMTS in head-end are scanned  5730 . If no port is available on the head-end  5732 , the open CMTS slots head-end is scanned  5734 . If no slot is available on the head-end  5736 , new CMTS is added in the head-end  5738 , a line card is added  5740  and a port is added to the new SG  5742 . Then, X is incremented  5744 . 
     If no action required  5746 , then X is incremented  5748 . If a port is available on the CMTS  5750 , then a port is assigned to a new SG  5752 . Then, X is incremented  5754 . 
     If a port is available on the head-end  5756 , then assign a port to the new SG  5758 . Then, X is incremented  5760 . 
     If a slot is available on the head-end  5762 , then add a line card  5764  and assign a port to the new SG  5766 . Then, X is incremented  5768 . 
       FIG. 58  is a flow chart  5800  showing the DS service group optimization. Data that includes the service group  5810 , market  5812 , CMTS  5814 , node ID list  5816 , the current number of subscribers  5818 , the number of channels  5820 , and HHP for each node  5822  is provided. A single service group is then examined  5824 . If the number of SG channels is less than the number of channels required  5826 , then an EQAM channel is added  5828 . If the number of SG channels is greater than or equal to the number of channels required  5830 , then utilization is examined  5832 . 
     Utilization is examined by first determining if the number of SG subscribers  5834  is less than the maximum number of subscribers per channel  5836  times the number of channels per service group  5838 . If so, then terminate the process  5842 . 
     If the number of SG subscribers  5844  is greater than or equal to the maximum number of subscribers per channel  5846  times the number of channels per service group  5848 , then examine the EQAM channel. If the number of EQAM Channels  5852  is less than the maximum number of channels per EQAM port  5854 , than add an EQAM channel  5856  and loop to the utilization examination step  5832 . If the number of EQAM Channels  5858  is equal to the maximum number of channels per EQAM port  5860 , examine the nodes in the SG. If nodes in SG is greater than one  5864 , then decombine the node into new downstream and old downstream  5866 . If nodes in SG are equal to one  5868 , then split the node into new downstream and old downstream  5870 . Update subscribers for each SG, update HHP for each new node, and reduce to only 1 legacy channel  5872 . Then, return to examine another SG  5824 . 
       FIG. 59  is a block diagram of a system  5900  according to an embodiment of the invention. In  FIG. 59 , granular data is collected from the cable system  5910 . The granular data may include data on users, demographic parameters, speed tiers, application mixes, etc. The data may be collected in a database system  5912  having storage  5914  for the granular data. Capacity planners  5930  may access the servers  5920  of the database system  5912  to reconstruct the consumption down at the user level. Rather than take such a top down view of the network capacity world, a bottom up view is reconstructed by capacity planners  5930 . 
     From the granular data, the capacity planner  5930  uses the planning system to project bandwidth capacity planning upwards. For example, how much bandwidth each individual user would consume is gathered and then a model is built using the system to move upwards and determine how much capacity is needed for a particular fiber node  5940 . Capacity for a group of fiber nodes, e.g., a service group  5942 , is determined using the data associated with particular fiber nodes. This process then continues up to an interface  5944  on an access device, a particular access device  5946 , and thereon through to the network  5948 . Accordingly, a determination of how much actual consumption, whether on an application basis, on a group, on granular basis such as protocols or even on the cable side itself. 
     Once these calculations have been made, the model  5950  run by the capacity planners  5930  allows projections to be made and a compound annual growth rate may be determined. The compound annual growth rate may be used to make projections based on what is currently known. This model  5950  may be applied to the application usage, to the overall usage, to whatever specific portion of that consumption is of interest. By pushing this analysis forward, projections may be made further out in time what the actual demand will be so that the plant is not overbuilt unless so desired. If overbuilding the plant is desired, the model allows planners to move the end of the line more towards the consumption side, i.e., the demand curve. 
     Planners  5930  may also decide to move the line more towards the retail curve so that an understanding of what that impact of such a move would be on user experience, e.g., what will be the impact on the number of customer trouble tickets that are generated. Moreover, actually knowledge of vendor hardware may be used to assign hardware and cause actions to occur accordingly, e.g., node splits, etc. 
     Embodiments may be implemented in a suitable computing environment. Embodiments may also be implemented in combination with other types of computer systems and program modules. Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. By way of example, computer readable media  5990  can include computer storage media and communication media. Computer storage media  5990  includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information  5992 , such as computer readable instructions, data structures, program modules or other data. Computer storage media  5990  typically embodies computer readable instructions, data structures, and program modules. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Embodiments may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. 
     Embodiments implemented on computer-readable media  5990  may refer to a mass storage device, such as a hard disk or CD-ROM drive. However, it should be appreciated by those skilled in the art that computer-readable media can be any available media that can be accessed or utilized by a processing device, e.g., server or communications network provider infrastructure. 
     By way of example, and not limitation, computer-readable media  5990  may include, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, digital versatile disks (“DVD”), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a processing device. 
     As mentioned briefly above, a number of program modules and data files may be stored and arranged for controlling the operation of processing devices. Thus, processing devices, such as server  5920 , may be configured to execute instructions that perform the operations of embodiments of the present invention. 
     It should also be appreciated that various embodiments of the present invention can be implemented (1) as a sequence of computer implemented acts or program modules running on a processing device and/or (2) as interconnected machine logic circuits or circuit modules within the processing devices. The implementation is a matter of choice dependent on the performance requirements. Accordingly, logical operations including related algorithms can be referred to variously as operations, structural devices, acts or modules. It will be recognized by one skilled in the art that these operations, structural devices, acts and modules may be implemented in software, firmware, special purpose digital logic, and any combination thereof without deviating from the spirit and scope of the present invention as recited within the claims set forth herein. 
     Accordingly, embodiments of the invention use the available data to build and associate the requirements from the customer upwards rather than the network downwards. Thus, rather than determining how much network capacity there is and how much a subscriber can have, embodiments of the present invention project how much bandwidth is needed and identifies what it will take to provide that bandwidth. 
     The foregoing description of the exemplary embodiment of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not with this detailed description, but rather by the claims appended hereto.