WO2001075633A1

WO2001075633A1 - Systems and methods for managing a network

Info

Publication number: WO2001075633A1
Application number: PCT/US2001/008908
Authority: WO
Inventors: Forrest D. Buttry, Jr.
Original assignee: Mci Worldcom, Inc.
Priority date: 2000-03-31
Filing date: 2001-03-20
Publication date: 2001-10-11
Also published as: AU2001247607A1

Abstract

A network management system (100) enables a network manager (140) to manage a number of networks (180, 190) in a shared management environment. The system stores templates for customizing an interface for displaying network-related information. The system receives inputs from users (110, 120, 130, 150, 160, 170) representing requests for network management services. The system then determines whether the necessary information has been provided before assuming control of the network. The system also manages changes to a customer's network in a standardized manner to ensure that all necessary information has been provided before implementing the change.

Description

SYSTEMS AND METHODS FOR MANAGING A NETWORK

FIELD OF THE INVENTION

The present invention relates to telecommunications networks and, more particularly, to systems and methods for managing a telecommunications network.

BACKGROUND QF THE INVENTION

Companies today have become increasingly reliant upon their network equipment in order to transact their daily business. For example, many companies now sell products or provide customer support information via the Internet. Other companies have increased the size of their internal networks to permit their employees to access information in 3 more efficient manner. As a result, companies must now take steps to ensure that their network equipment, such as switches and routers, is reliable.

Many companies address this issue by "outsourcing" the management of their networks. That is, the company delegates all or some of the duties associated with actively managing their network to another party, e.g., a network manager. The network manager may manage networks for many different companies. As a result, the network manager typically manages many different types of networks, where each network may include hundreds or even thousands of individual network devices. As the total number of networks managed increases, it becomes more difficult to effectively manage the networks in a shared management environment. For example, the logistics involved in managing change requests from companies regarding their respective networks, which typically have unique criteria pertaining to their particular network equipment, often results in scheduling problems. Such scheduling problems may lead to delays in approving changes to a company's network, resulting in network downtime.

Another drawback typically faced by network managers is that it is difficult for personnel associated with the network manager to¹ learn all the nuances of each particular network being managed. That is, due to each company's unique criteria regarding their network, the learning curve for network management personnel is typically long. This makes it especially difficult for the network manager to efficiently manage various networks in a shared management environment.

SUMMARY OF THE INVENTION

There exists a need for systems and methods that facilitate the management of networks.

There is also a need for systems and methods that simplify the process associated with making changes to a managed network. These and other needs are met by the present invention, where a server interfaces with users representing customers. When the customer wishes to outsource the management of a network or change the configuration of a network already actively managed by the server, the customer transmits a request to the server. The server, interacting with the customer and network management personnel, requests specific ^' information from the customer before accepting control of the customer's network or before implementing any changes to the customer's network. According to one aspect of the invention, a method for managing change requests

is provided in a system including at least one server for managing a network. The method includes receiving, at the server, an input from a user, the input representing a request for a change associated with the network managed by the server. The method

also includes automatically notifying a network management entity of the requested change in the network and assessing an impact of the requested change to the network. Another aspect of the present invention provides a computer-readable medium that includes stored sequences of instructions that are executed by a processor. The instructions cause the processor to receive an input from a user, the input representing a request for a change associated with a first one of a plurality of networks. The instructions further cause the processor to automatically notify a network management entity of the requested change in the first network and assess an impact of the requested change to the first network.

In still another aspect of the invention, a method for managing a plurality of networks having unique requirements is provided. The method includes receiving, from a user, a request for network management services. The method also includes receiving network-related information from the user and creating a customized interface for displaying the network-related information.

In yet a further aspect of the invention, a method for assuming control of a customer network in a system including at least one server for managing a plurality of customer networks is provided. The method includes receiving, at the server, an input from a user, the input representing a request for network management services. The method also includes transmitting an input form to the user, the input form representing a request for network-related infoπnation and receiving the network-related information from the user. The method further includes checking whether predetermined network related-information has been received and determining whether to assume control of the •network for management by the server. Other features and advantages of the present invention will become readily apparent to those skilled in this art from the following detailed description. The embodiments shown and described provide illustration of the best mode contemplated for carrying out the invention. The invention is capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawings arc to be regarded as illustrative in nature, and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS Reference is made to the attached drawings, wherein elements having the same reference number designation represent like elements throughout.

Figure 1 is an exemplary system in which methods and systems consistent with the present invention may be implemented.

Figure 2 is a block diagram of an exemplary server illustrated in Figure I,

consistent with the present invention.

Figure 3 is a flow diagram, consistent with the present invention, illustrating exemplary processing for approving a new customer network. Figure 4 is a flow diagram, consistent with the present invention, illustrating exemplary processing for assuming control of a customer network.

Figure 5 is an exemplary interface screen consistent with the present invention. Figure 6 is a flow diagram, consistent with the present invention, illustrating exemplary processing for managing change requests to a customer's network.

DETAILED DESCRIPTION Systems and methods consistent with the present invention provide an efficient mechanism for proactively managing customer networks in a shared management environment. Customers provide specific information relating to their respective networks and network management personnel, interacting with a server, enter the information into the server. The server facilitates the entry of the customer information in a standardized manner, thereby simplifying the process for accepting new customer networks or modifying existing customer network information. By providing a standardized approach, the knowledge requirements for network management personnel associated with managing the customers' networks is significantly reduced.

SYSTEM OVERVIEW Figure 1 is a block diagram of an exemplary, system 100 in which methods and systems consistent with the present invention may be implemented. The system 100 includes a plurality of client devices 110, 120 and 130, a server 140. a plurality of ' management devices 150, 160 and 170 and networks 180 and 190.

The client devices 110, 120 and 130 may each include any type of computer system, such as a personal computer, a laptop or a personal digital assistant (PDA), with a connection to network 180. In an exemplary implementation consistent with the present invention, the client devices 1 10, 120 and 130 may also include "dumb" terminals with a connection to network 180. The client devices 110, 120 and 130, consistent with the

present invention, represent customers associated with networks actively managed, or proposed to be managed, via server 140. For example, client device 1 10 may represent a

point of contact (POC) associated with a company for which server 140 proactively manages a network (not shown). Similarly, client devices 120 and 1 0 may each represent different respective companies for which server 140 proactively manages a network. The client devices 110, 120 and 130 may establish communication with server 140 over network 180 via a wired, wireless, or optical connection. The network 180 may include the Internet, a local area network (LAN), a wide area network (WAN), an intranet or another type of network. In alternative implementations, client devices HO, 120 and 130 may connect directly to server 140.

The server 140 may include any type of computer system, such as a mainframe, minicomputer or personal computer, which includes a connection to network 180 to enable server 140 to communicate with client devices 110, 120 and 130. In alternative implementations, the server 140 may include a mechanism for directly connecting to client devices 110, 120 and 130. The server 140 also includes a mechanism for

communicating with management devices 150, 160 and 170 via network 190. The server 140, consistent with the present invention, provides a forum through which client devices 1 10, 120 and 130 communicate customer network information. The server 140 provides a standardized process for managing the customer networks, as described in more detail below. The server 140 may transmit data over network 180 and network 190 via wired, wireless or optical connections. The management devices 150, 160 and 170 may each include any type of computer system, such as a personal computer, a laptop or a PDA. with a connection to network 190. In an exemplary implementation consistent with the present invention, the management devices 150, 160 and 170 may also include dumb terminals with a connection to network 190. The management devices 150, 160 and 170, consistent with the present invention, may be used by personnel, such as a network engineer, for managing a customer's network. For example, management device 150 may be used by a network engineer to manage a network associated with a customer represented by client device 110. The management devices 150, 160 and 170 may establish communication with server 140 over network 190 via a wired, wireless, or optical connection. The network 190 may include the Internet, a LAN, a WAN, an intranet or another type of network. In alternative implementations, management devices 150, 160 and 170 may connect directly to server 140.

Only three client devices 110, 120 and 130, three management devices 150, 160 and 170, and a single server 140 are shown for simplicity. It should be understood, however, that additional client devices, management devices and servers may be included in system 100, as described in more detail below.

EXEMPLARY SERVER Figure 2 is an exemplary diagram of server 140 of Figure I. The server 140 includes a bus 210, a processor 220, a memory 230, a read only memory (ROM) 240, a storage device 250, an input device 260, an output device 270, and a communication interface 280. The bus 210 permits communication among the components of the server 140.

The processor 220 may include any type of conventional processor or

microprocessor that interprets and executes instructions. The memory 230 may include a 5 random access memory (RAM) or another dynamic storage device (referred to as main memory) that stores information and instructions for execution by the processor 220. Main memory 230 may also be used to store temporary variables or other intermediate information during execution of instructions by processor 220.

ROM 240 may include a conventional ROM device and/or another static storage

) . 0 device that stores static information and instructions for processor 220. The storage device 250 may include a magnetic disk or optical disk and its corresponding drive and/or some other type of magnetic or optical recording medium and its corresponding drive for storing information and instructions.

The input device 260 may include any conventional mechanism that permits an 5 operator to input information to the server 140, such as a keyboard, a mouse, a pen, voice recognition and/or biomctric mechanisms, etc. The output device 270 may include any conventional mechanism that outputs information to the operator, including a display, a printer, a pair of speakers, etc. The communication interface 280 may include any transceiver-like mechanism that enables the server 140 to communicate with other devices and/or systems, such as the client devices 110-130. For example, the communication interface 280 may include a modem or an Ethernet interface to a LAN. Alternatively, communication interface 280 may include other mechanisms for

communicating via a network, such as networks 180 and 190. The server 140, consistent with the present invention, provides a forum through which customer networks may be proactively managed in an efficient manner.

I ;

According to one implementation, the server 140 provides for the management of ' t customer networks in response to processor 220 executing sequences of instructions contained in memory 230. Such instructions may be read into memory 230 from another computer-readable medium, such as a data storage device 250, or from a separate device via communication interface 280. Execution of the sequences of instructions contained in memory 230 causes processor 220 to perform the process steps that will be described hereafter. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to Implement the present invention. Thus, the present invention is not Limited to any specific combination of hardware circuitry and software.

EXEMPLARY PROCESSING FOR APPROVING A CUSTOMER NETWORK Processing consistent with the present invention enables a customer, via a client device, to submit information to a server, such as server 140, for managing the customer's network. Server 140 then interacts with management personnel, such as a network engineer, via a management device 150, 1 0, or 170, for approving and assuming control of a customer's network.

Figure 3 is an exemplary flow diagram, consistent with the present invention, illustrating processing associated with server 140 interacting with a user and management personnel for approving a new customer network for entry in the shared management system of server 140. Processing begins when a user, i.e., a customer, establishes a connection to the server 140 via a client device, such as client device 1 10 (step 310). The customer may, for example, accomplish this via any conventional Internet connection by

entering the uniform resource locator (URL) associated with the server 140. When connection to the server 140 is established, the customer may optionally receive a login screen prompting the customer to enter a user identifier (ID) and password (step 320). The customer enters an ID and password associated with that particular customer and transmits the information to the server 140. If the customer is a new customer, the server 1 0 may request additional preliminary information. In alternative embodiments of the invention, step 320 may be bypassed. Next, the server 140 downloads a selection screen to the customer (step 330), The selection screen may include options such as "Add a New Network," and "Modify an Existing Network." Other selection options may also be included in the selection screen. Suppose the customer selects "Add a New Network." The server 140 then downloads a customer information screen to the customer's client device (step 340). The customer information screen may include requests for information regarding customer contact information. For example, the customer information screen may include a request for

customer contacts for each site for which network management services are desired. This information provides the server 140 a POC with which to verify service and/or obtain approval for all network issues, as needed. The server 140, consistent with the present invention, may request specific contact information including: 1) a customer POC name and complete telephone number and facsimile number (including international prefix, if applicable); 2) after hours POC name and phone number (if different); 3) address information; 4) shipping address (if different from address information); and 5) local language requirement (e.g., Spanish, Chinese, etc.). This information facilitates the management of the customer's network by ensuring that the server 140 has adequate contact information and is aware of any particular requirements associated with each customer. Other initial customer information may be necessary based on the customer's particular requirements.

Next, the server 140 notifies a network management device of the request for approval of a new network (step 350). This notification may be transmitted to a management device, such as management device 150, over network 190. A member of the network management team, e.g., a network engineer, receives the notification, via the management device, and contacts the POC provided by the customer to request additional information (step 360). This additional information may include requests for detailed information regarding the customer's network. For example, the network engineer may request network topology information, circuit identification information, as-built network drawings, router configuration drawings, equipment layout diagrams, etc. The network engineer may also request information regarding special procedures that relate to specific sites within the customer's network.

The network engineer may also request information regarding the customer provided equipment (CPE) included in the network. For example, if the CPE includes a switch made by Newbridge Networks, the customer may have a contract with a particular vendor to maintain that switch. In this case, the network engineer may request additional information including: 1) does a maintenance contract exist for any of the CPE and/or what is the respective contract number, vendor, and expiration date; 2) vendor contact/escalation telephone numbers and instructions as to how the vendor would like to be informed about equipment problems; and 3) hours of coverage or support by the

vendor or some related party.

In essence, the network engineer gathers all of the necessary information associated with proactively managing the customer's network. The particular information gathered varies based on the particular customer network. However, in all cases, the network engineer gathers sufficient information to provide for the efficient management of the customer's network.

The customer may provide the detailed network information to the customer engineer in any convenient manner. For example, if the network topology drawings exist in electronic form, the customer may transmit the files to the network engineer via electronic mail (email). Providing the information in electronic form simplifies the eventual entry of this information into the server 140. Alternatively, the customer may provide the information to the network engineer in any other form.

After the network engineer receives the customer's network information, the network engineer determines whether all the necessary information regarding the customer's network has been provided (step 370). According to an exemplary implementation consistent with the present invention, the network engineer's determination may include checking one or more of the following: 1) whether the customer POC information has been provided; 2) whether the vendor information has been provided; 3) whether the international contact information has been provided, when applicable; 4) whether the network documentation information has been provided; 5) whether any required internal network/circuit testing has been completed; 6) whether any required test access requirement has been completed; 7) whether an equipment sparing arrangement plan has been completed; 8) whether internal training requirements have been completed; 9) whether trouble reporting requirements have been provided; 10) whether any required dialup access requirements have been provided; and 1 1) whether

additional levels of support information regarding the customer's network have been provided.

The particular checks described above may be based on the particular customer network and customer requirements. For example, a particular customer network may require an end-to-end (ETE) circuit test with a local telephone service provider before the network testing may be considered complete. Other tests may be required based on the particular type of customer network. If all the necessary information has not been provided, processing returns to step 360 and the network engineer requests the necessary information that has not been provided. After all the necessary information has been provided, the network engineer determines whether to approve the customer's network for inclusion in the shared management system of server 140 (step 380). Assume that the network engineer approves the network for inclusion in server

140. The information provided by the user may then be entered into the server 140 to enable the server 140 to assume control of the new customer network, as described in detail below.

EXEMPLARY PROCESSING FOR ASSUMING CONTROL OF A CUSTOMER NEWTORK

Figure 4 illustrates exemplary processing associated with server 140 assuming control of a new network. Processing begins when a user, e.g., a network engineer. establishes a connection with server 140 in a conventional manner via a management

device, such as management device 150 (step 410). The server 140 transmits a login screen to the management device 150 and the network engineer enters a user ID and

password (step 420). The server 140 determines whether the network engineer is authorized to enter information pertaining to a. new network. Assuming that the network engineer is authorized, the server 140 provides an indication that access to the files stored on server 140 has been granted.

The server 140, consistent with the present invention, stores a number of files that facilitate adding new networks into server 140. These files may be stored in storage device 250 (Figure 1). Alternatively, these files may be stored on any other computer- readable medium accessible to server 140. The files are essentially templates that may be used to create a standardized graphical user interface (GUI) for displaying the customer's information. These files also significantly simplify the process for entering the customer network information. According to an exemplary implementation, the files are stored in a Windows-based system on server 140. To begin entry of a new network, the network engineer selects "FILE" from a menu and then selects "NEW" under a sub-menu. The server 140 automatically provides a "New Folder" icon, along with a prompt for entering a folder name (step 430). The network engineer may enter the folder name to correspond to the customer name. This facilitates finding the folder when changes may be needed at

a later time.

The network engineer may now customize the network management interface based on the customer's network information provided at step 360 (Figure 3). First the

network engineer copies the files associated with each screen that will form part of the GUI used to proactively manage the customer's network. According to an exemplary implementation, the GUI includes a home page, a network overview screen, a general procedures screen, a site specific information screen, an escalation information screen and a disaster recovery screen, as described in more detail below. It should be noted that each screen may include several individual screens or pages that may be linked, as described in more detail below.

After copying the appropriate files to the new network folder, the network engineer customizes these files with the customer's specific network information (step 440). For example, using a conventional software editor, such as a hyper text markup language (HTML) editor, the network engineer customizes the customer home page to include the customer's name and optionally a customer logo. The home page may also include the name of a project engineer or network engineer responsible for managing that customer's network.

Figure 5 illustrates an exemplary home page 500 consistent with the present invention. As illustrated in Figure 5, the customer home page 500 may include a links area 510, an identification area 520, an index area 530 and a responsible party area 540. The links area 510 provides links to other screens. In the exemplary home page 500, these include links to a network overview screen, a general procedures screen, a site specific information screen, an escalation information screen and a disaster recovery screen. The identification area 520 includes the customer's name and an optional customer logo. The index area 530 includes a list of other screens relating to the customer's network. The responsible party area 540 includes the name of a person, such as a project engineer, responsible for managing the customer's network. The particular information on the customer home page 500 may be further customized, based on the customer's particular network to facilitate the use of the information by paπies responsible for managing the customer's network.

The network engineer similarly customizes the other screens to store information about the customer and the customer's network. For example, the network overview screen may contain introductory information about the customer, such as the customer's type of business. The network overview screen may also include a brief text description of the customer's network and list of the customer's network equipment. This screen may include links to additional screens that display network topology diagrams and other diagrams illustrating how the customer's network is configured and managed. These diagrams are entered into the server 140 from the customer-supplied information gathered by the network engineer.

The general procedures screen stores procedure guidelines that pertain to this specific customer. For example, this screen may display maintenance procedures associated with the customer's network equipment, trouble reporting procedures, procedures for notifying the customer of any particular network-related information, etc. When a customer engineer selects this page, a pop-up browser window may appear to get the attention of the customer engineer for conveying important information.

The site specific screen displays customer site information. This includes circuit IDs, as-built circuit network diagrams, router configuration diagrams, engineering orders associated with new/modified equipment for the network, equipment layout diagrams, etc. Any special procedures that relate to specific sites within the customer's network may also be included here. This screen may also provide links to other necessary information. For example, links to network overview diagrams stored under the network overview screen, local topology maps, customer equipment room location maps. etc. These links simplify the task associated with efficiently managing the customer^'s network. The escalation information screen includes POC information at the customer location. This POC information may also include alternates to call when a first contact is unavailable. Telephone numbers, pager numbers, email addresses may be included under the escalation information screen. This information may be required when problems with the customer's network arise. The disaster recovery screen stores specific procedures to be followed if a major failure in the customer's network occurs. Such procedures are based on the particular customer's network and the customer's particular requirements.

In summary, the network engineer gathers all the necessary customer network information and stores the information in a customized, user- friendly GUI system on server 140 (step 450). After storing the customized information, the network engineer sets a time for when the server 140 is to assume control of the customer's network (step 460). The GUI stored on server 140 may then be used to display network information for a customer's network that is proactively managed via server 140. Using a standardized GUI greatly reduces the knowledge requirements to proactively manage a customer's network. When a network engineer, or any other network management personnel, wishes to get an understanding of a particular customer's network, that par y may simply access the server 140, enter a particular customer^'s identification information and view the customer's network information. Since the overall format of the GUI is standardized for all customers, the network engineer can find the particular information he/she is looking for in the same location for each of the networks. This significantly reduces the time required for a network engineer to learn important details associated with the customer's

network. The server 140 also provides a centralized location from which to coordinate changes to a customer's network. These changes may involve scheduled and unscheduled, customer-initiated physical or logical configuration changes to an existing customer's CPE. These changes may also involve scheduled and unscheduled, customer- initiated maintenance of CPE that may affect services provided by the network manager. These changes may further include network manager scheduled and unscheduled maintenance operations. All other changes such as installations and modifications (adds, changes, disconnects, and moves) of sites, ports and private virtual circuits (PVCs) may be managed through the change management process, described in more detail below.

EXEMPLARY PROCESSING FOR MANAGING CHANGES TO A CUSTOMER NETWORK

Figure 6 illustrates exemplary processing for managing changes to a customer's network. Processing begins when a customer, via a client device, such as client device 1 10. establishes a connection to server 140 in any conventional manner, e.g., entering a URL associated with server 140 (step 610). The server 140 downloads a login screen and the customer provides a user ID and password (step 620). Assuming that the customer is authorized to request changes, the server 140 provides a selection screen indicating several options (step 630). These options may include "Add a New Network," and "Modify an Existing Network." Suppose the customer selects "Modify an Existing Network.^*' The server 140 downloads a change request screen to the customer's client device (step 640).

According to an exemplary implementation, the change request screen may request the customer to provide: 1) a clearly stated change request; 2) a requested due date and time for the change to be completed; 3) site specifics for existing services such as site name, card, port, PVC, and Internet Protocol (IP) address, where applicable; 4) requester's name, callback telephone number and/or paging instructions; 5) contact name and telephone number for time that the activity is scheduled to be performed; and 6) a site address. The customer provides the requested information to server 140 (step 650).

After receiving this information from the customer, the server 140 automatically transmits this information to a management device, such as management device 1 0, associated with the network engineer responsible for that customer's network (step 650). In alternative implementations, the server 140 may transmit a pager message or another type of message to a part (ies) associated^' ith the particular customer to provide notification of the change request. In this scenario, the server 140 stores information, e.g., pager numbers, email addresses, etc. associated with the appropriate personnel concerned with the particular customer's network. Upon receiving the notification, the network engineer determines whether all the required information regarding the network change has been provided. This required information may be based on the particular change request and the particular customer network. At a minimum, the required information includes a list of equipment affected by the change request. The network engineer then performs a network impact assessment and determines whether to approve or disapprove the change request (step 6b0). In alternative implementations consistent with the present invention, the server 1 0 may perform the steps of assessing the network impact and determining whether to approve the change request. In this scenario, the server 140 may be programmed with particular criteria for evaluating each change requests, based on the particular customer requirements.

The network engineer transmits the approval/disapproval determination to the server 140. If the network change is not approved, the server 140 then notifies the customer of the disapproval of the change (step 670). The server 140 may also provide reasons why the change was not approved. For example, if the change request could not be performed within the desired time, the network engineer may disapprove the change and transmit this reason for the disapproval to the customer.

If the network change is approved, the server 140 notifies the appropriate personnel associated with actively managing the customer's network. Such personnel may include a project engineer, operations and maintenance personnel, account managers for that customer, billing specialists for that customer, etc.

According to an exemplary implementation of the present invention, after a change has been approved, the server 140 schedules the change and generates a "service ticket" to track the approved change (step 680). The service ticket is essentially an electronic ticket used to track the progress of work associated with implementing the change. If the change is designated as an emergency change, the ticket may reflect an increased priority. According to an exemplary implementation, the service ticket includes a customer ID and an associated priority and may be transmitted to parties associated with implementing the change. The ticket may be transmitted via a paging system, an email system or an other type of notification system. After the work associated with implementing the change request has been completed, the network engineer verifies the changes have been made, updates the information stored in server 140 relevant to the changes and closes the service ticket (step 690).

Described has been a system and method for managing networks. An advantage of the invention is that network management personnel, interacting with server 140, may customize an interface to facilitate managing a customer's network. Another advantage of the invention is that the interface for each customer uses a standardized template, thereby simplifying network management personnel's tasks in efficiently managing the network and reducing errors. A further advantage of the invention is providing systematic procedures for accepting control of a new network and for accepting changes to an existing network. Using such a systematic approach further ensures that customer networks will be efficiently managed.

In this disclosure, there is shown and described only the preferred embodiments of the invention, but, as aforementioned, it is to be understood that the invention is capable of use in various other combinations and environments and is capable of changes or modifications within the scope of the inventive concept as expressed herein. For example, the processes for approving a customer network, assuming control of a customer network and managing changes for an existing customer network have been described in conjunction with server 140 interacting with customers and management personnel via management devices. In alternative implementations c_onsis_ten_{t w}i_th _the pr_es_en_t invention, the server 140 may transmit s^tandardized forms to the customer's client device, where each form requests specific ⁱnformation. The server 140 may _then automatically use this information to populate the various in^terface screens

described in relation to Figure 4, without management personnel having to interact with the customers to obtain the network information in other conven^tional ways. The details of automatically generating the interface screens using the customer-supplied information are not disclosed herein as such programming steps can be determined by one of ordinary

skill in the art from the figures and functions described herein.

Claims

WHAT IS CLAIMED IS:

1. In a system comprising at least one server for managing a network, a method for managing change requests, comprising:

receiving, at the server, an input from a user, the input representing a request for a change associated with the network managed by the server; automatically notifying a network management entity of the requested change in the network; and assessing an impact of the requested change to the network.

2. The method of claim 1, further comprising: determining whether to approve the requested change based on the impact.

3. The method of claim 2, further comprising: modifying information stored in the server associated with the network, after the network change has been approved.

4. The method of claim 1, further comprising: determining whether the requested change represents an emergency change request; and generating an electronic ticket to track the change, the electronic ticket indicating a priority related to the change.

5. The method of claim 1, wherein the change request represents at least one of an equipment configuration change, a maintenance activity change and a customer notification change.

I t 6. The method of claim I, further comprising: determining whether predetermined information regarding the change request has been provided, before assessing the impact.

7. The method of claim 6, wherein the predetermined information includes a list of equipment affected by the change request.

8. Λ computer-readable medium having stored thereon a plurality of sequences of instructions, said sequences of instructions including sequences of instructions which, when executed by a processor, cause said processor to perform the steps of: receiving an input from a user, the input representing a request for a change associated with a first one of a plurality of networks; automatically notifying a network management entity of the requested change in the first network; and assessing an impact of the requested change to the first network.

9. The computer-readable medium of claim 8, causing said processor to perform the further steps of: determining whether to approve the requested change based on the impact; and modifying stored information associated with the first network, after the network change has been approved.

10. The computer-readable medium of claim 8, causing said processor to perform the further steps of: determining whether the requested change represents an emergency change request; and generating an electronic ticket to track the change, the electronic ticket indicating a priority related to the change.

11. The computer-readable medium of claim 8, wherein the change request represents at least one of an equipment configuration change, a maintenance activity change and a customer notification change.

12. The computer-readable medium of claim 8, causing the processor to perform the further step of: determining, before assessing the impact, whether predetermined information regarding the change request has been provided, wherein the predetermined information includes a list of equipment affected by the change.

13. A system for managing a plurality of networks, comprising: a memory configured to store a plurality of templates, wherein each of the plurality of templates may be customized for each of the plurality of respective networks; and a processor coupled to the memory and configured to: receive inputs from a user, the inputs representing network information associated with the user's network, customize a user interface for displaying the network information based on the templates and the inputs, and store the customized user interface in the memory.

14. The system of claim 13, wherein the inputs represent customer contact information and network equipment information.

15. The system of claim 14, wherein the inputs further represent vendor information regarding the network equipment and trouble reporting procedures.

16. The system of claim 13, wherein the user interface comprises a network overview screen, a procedures screen and a site specific information screen.

17. The system of claim 16, wherein the user interface further comprises an escalation information screen and a disaster recovery screen.

18. The system of claim 13, wherein the user interface comprises a home page screen that provides links to at least one of a network overview screen, a procedures screen, a site specific infoπnation screen, an escalation information screen and a disaster recovery screen.

19. A method for managing a plurality of networks, wherein each of the plurality of networks has unique requirements; comprising: receiving, from a user, a request for network management services; receiving network-related information from the user; and creating a customized interface for displaying the network-related information.

20. The method of claim 19, further comprising: storing the customized interface on a server; and providing access to the server to authorized parties.

21. A system for managing a plurality of networks, comprising: means for storing information associated with each of the plurality of networks;_. means for receiving an input from a user, the input representing a request for a change associated with a first one of the plurality of networks managed by the server; means for assessing an impact of the requested change to the first network; and means for automatically determining whether to approved the requested change based on the impact.

22. In a system comprising at least one server for managing a plurality of customer networks, a method for assuming control of a customer network for management by the server, comprising: receiving, at the server, an input from a user, the input representing a request for network management services; transmitting an input form to the user, the input form representing a request for network-related information; receiving the network-related information from the user; checking whether predetermined network-related information has been received; and determining whether to assume control of the network for management by the server.

23. The method of claim 22, wherein the checking includes: determining whether customer contact information has been provided, determining whether network equipment information has been provided, and determining whether vendor information regarding the network equipment has been provided.

24. The method of claim 23, wherein the checking further includes: determining whether network testing has been completed, and determining whether equipment sparing information has provided.