Abstract:
In a system and method for managing a complex network, including an access network, a metro network, or the like, the method includes the steps of: requesting, at a first terminal, call set-up to perform the Voice over Internet Protocol (VoIP) call with a second terminal; collecting available bandwidth information of an access network to which each of the first and second terminals belongs, and available bandwidth information of a metro network linked to the access network; and allowing the call set-up request when the available bandwidths of the access network and the metro network are larger than a bandwidth for the VoIP call. Accordingly, resources and performance of the complex network can be continuously controlled, and a high-quality and large-capacity service Quality of Service (QoS) guarantee can be provided.

Description:
CLAIM OF PRIORITY 
       [0001]    This application makes reference to, incorporates the same herein, and claims all benefits accruing under 35 U.S.C.§119 from an application for COMPLEX NETWORK MANAGEMENT SYSTEM AND METHOD THEREOF earlier filed in the Korean Intellectual Property Office on the 18 Jan. 2006 and there duly assigned Serial No. 10-2006-0005564. 
       BACKGROUND OF THE INVENTION 
       [0002]    1. Technical Field 
         [0003]    The present invention relates to a complex network control system for controlling and managing mutually different networks such as an access network and a metro network, and a method thereof. 
         [0004]    2. Related Art 
         [0005]    In a general access network and a metro network, users have been supplied with voice, data, and broadcast services via separate, respective networks such as a voice network, a data network, and a broadcast network. However, recent technological trends toward wired/wireless integration and broadcast/communication integration have resulted in considerable research and development aimed at building a Next Generation Network (NGN) which can provide users with voice, data, and broadcast services via a single integrated network. 
         [0006]    It is expected that a core network in the NGN will be built based on Multi Protocol Label Switching (MPLS). It is also expected that a metro network will be built as an IP-based packet network. In contrast, it is expected that access networks will be built as various wired and/or wireless networks. 
         [0007]    As such, in order to provide subscribers with guaranteed Quality of Service (QoS) via the NGN into which various types of the networks are converged, a QoS control management mechanism should be introduced into the access and metro networks. 
         [0008]    Conventional IP-based access and metro networks have been operated on the basis of maximum efficiency, and thus could not provide users with guaranteed QoS services. To cope with this problem, class-based QoS mechanisms, such as Diffserv, 802.1p/q, and the like, were introduced. However, continuous control management after initial setting was not reflected. Furthermore, different access networks are managed by different control methods, and thus seamless QoS cannot be guaranteed for communication between heterogeneous networks. 
       SUMMARY OF THE INVENTION 
       [0009]    It is an object of the present invention to provide a complex network control system for controlling and managing mutually different networks such as an access network and a metro network, and a method thereof. 
         [0010]    A first aspect of the present invention provides a method of controlling a Voice over Internet Protocol (VoIP) call between first and second terminals belonging to heterogeneous access networks, the method comprising the steps of: requesting, at the first terminal, call set-up to perform the VoIP call with the second terminal; collecting available bandwidth information of an access network to which each of the first and second terminals belongs, and available bandwidth information of a metro network linked to the access network; and allowing the call set-up request when the available bandwidths of the access network and the metro network are larger than a bandwidth for the VoIP call. 
         [0011]    In this case, the method may further comprise the step of: identifying an optimal virtual path linking the heterogeneous access networks to each other using the available bandwidth information, and linking a call between the first and second terminals using the virtual path. 
         [0012]    In addition, the method may further comprise the step of: after the call set-up is completed according to the call set-up request, updating the available bandwidth information of the metro network and the access network to which the first and second terminals belong. 
         [0013]    A second aspect of the present invention provides a complex network management system which comprises at least one access network and a metro network, the system comprising: a Topology/Resource Management Module (TRM) for collecting and managing resource information of the complex network; a Policy Rule Decision Module (PRD) for determining a limit network resource authenticating a call transmitted to the access network or the metro network and a policy with respect to the limit network resource; and a Connection Admission Control Module (CAM) for comparing the network resource information with the limit network resource, and for determining whether a call set-up request to be transmitted to the complex network is allowed. 
         [0014]    In this case, the network resources may comprise at least one of topology, bandwidth, delay time, and delay variance of the network, and the access network may comprise at least one of an Active Optical Network (AON)-type Fiber To The Home (FTTH) network, a Passive Optical Network (PON)-type FTTH network, a Wibro Network, and a Wireless Local Area Network (WLAN). 
         [0015]    The complex network management system may further comprise a Policy Interface Module (PIM) for converting a policy received from the PRD to a protocol capable of being analyzed in each of the networks, and for transmitting the protocol to each of the networks. The PIM may identify a target network to which the policy is to be applied using a Management Information Base (MIB), and may generate a Command Line Interface (CLI) command or a Simple Network Management Protocol (SNMP) Object which is capable of being analyzed by the target network. 
         [0016]    In addition, the complex network management system may further comprise: a Traffic Monitoring Module (TM) for measuring traffic status of the complex network, and for notifying the PRD when the measured traffic exceeds the limit network resource; a fault management module for monitoring whether a fault occurs in a component of the complex network, and for notifying the PRD when a fault occurs; and a Performance Management (PM) module for collecting performance information of each component of the complex network, and for notifying the PRD when a fault occurs in performance of the component. 
         [0017]    The PRD may further comprise an event policy module which, upon receipt of at least one of a traffic exceeding event, a fault occurrence event, and a performance fault event of a component, displays the event to an operator, and delivers the policy for coping with the event to the PIM. 
         [0018]    In addition, the TRM may comprise a virtual path management module which determines an optimal virtual path linking heterogeneous access networks to each other using the resource information of the metro network, and a topology/resource table which stores the resource information of the complex network in the form of a list, and updates the resource information when the resource information changes. 
         [0019]    A third aspect of the present invention provides a method of managing a complex network composed of at least one access network and a metro network, the method comprising the steps of: collecting and managing resource information of the complex network; determining a limit network resource for authenticating a call to be transmitted to the access network or the metro network, and a policy with respect to the limit network resource; and comparing the network resource-information with the limit network resource, and determining whether a Call Admission Control (CAC) request to be transmitted to the complex network is allowed. 
         [0020]    The method may further comprise the step of converting the determined policy to a protocol capable of being analyzed in each of the networks, and transmitting the protocol to each of the networks. 
         [0021]    The network resources may comprise at least one of topology, bandwidth, delay time, and delay variance of the network, and the access network may comprise at least one of an Active Optical Network (AON)-type Fiber To The Home (FTTH) network, a Passive Optical Network (PON)-type FTTH network, a Wibro Network, and a Wireless Local Area Network (WLAN). 
         [0022]    The method may further comprise the steps of: measuring traffic status of the complex network, and displaying to an operator when the measured traffic exceeds the limit network resource; monitoring whether a fault occurs in components of the complex network, and displaying to an operator when a fault occur; and collecting performance information of the components of the complex network, and displaying to an operator when a fault occurs in the performance of a component. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0023]    A more complete appreciation of the invention, and many of the attendant advantages thereof, will be readily apparent as the same becomes better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings in which like reference symbols indicate the same or similar components, wherein: 
           [0024]      FIG. 1  is a block diagram showing the configuration of an access network and a metro network; 
           [0025]      FIG. 2  is a block diagram showing the configuration of a network including an Integrated Network Control Platform (INCP) in accordance with an exemplary embodiment of the present invention; 
           [0026]      FIG. 3  is a block diagram showing an internal configuration of a network including an INCP in accordance with an exemplary embodiment of the present invention; 
           [0027]      FIG. 4  is a flowchart showing the operation of a Policy Rule Decision Module (PRD) in accordance with another exemplary embodiment of the present invention; 
           [0028]      FIG. 5  is a flowchart showing the operation of a Topology/Resource Management Module (TRM) in accordance with still another exemplary embodiment of the present invention; 
           [0029]      FIG. 6  is a flowchart showing the operation of a Connection Admission Control Module (CAM) in accordance with yet another exemplary embodiment of the present invention; 
           [0030]      FIG. 7  is a flowchart showing the operation of a Traffic Monitoring Module (TM) in accordance with yet another exemplary embodiment of the present invention; 
           [0031]      FIG. 8  is a flowchart showing the operation performed when an event of a PRD is generated in accordance with yet another exemplary embodiment of the present invention; 
           [0032]      FIG. 9A  is a block diagram showing the configuration of a network for a VoIP call between a Passive Optical Network (PON) user and a Wibro user in accordance with yet another exemplary embodiment of the present invention; and 
           [0033]      FIG. 9B  is a flowchart showing the operation of the complex network control system of  FIG. 9A . 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0034]    Hereinafter, a complex network control system for controlling and managing mutually different networks, such as an access network and a metro network, according to the present invention will be described more fully with reference to the accompanying drawings. 
         [0035]      FIG. 1  is a block diagram showing the configuration of an access network and a metro network. 
         [0036]    In general, users have been supplied with voice, data, and broadcast services via separate, respective networks such as a voice network, a data network, and a broadcast network. However, recent technological trends toward wired/wireless integration and broadcast/communication integration have resulted in considerable research and development aimed at building a Next Generation Network (NGN) which can provide users with voice, data, and broadcast services via a single integrated network. It is expected that a core network  11  in the NGN will be built based on Multi Protocol Label Switching (MPLS) as shown in  FIG. 1 . It is expected that a metro network  12  will be built as an IP-based packet network. In contrast, it is expected that an access network  13  will be built as various wired and/or wireless networks. As such, in order to provide subscribers with guaranteed Quality of Service (QoS) via the NGN into which various types of the networks are converged, a QoS control management mechanism should be introduced into the access and metro networks. 
         [0037]    IP-based access and metro networks have been operated on the basis of maximum efficiency, and thus could not provide users with guaranteed QoS services. To cope with this problem, class-based QoS mechanisms such as Diffserv, 802.1p/q, and the like were introduced. However, continuous control management after initial setting was not reflected. Furthermore, different access networks are managed by different control methods, and thus seamless QoS cannot be guaranteed for communication between heterogeneous networks. 
         [0038]      FIG. 2  is a block diagram showing the configuration of a network including a complex network control system in accordance with an exemplary embodiment of the present invention. 
         [0039]    As shown in  FIG. 2 , a broadband network may be composed of an access network  23 , an IP-based metro network  22 , a Multi Protocol Label Switching (MPLS)-based core network  21 , and so forth. The kind and topology of such a network can be changed if necessary. 
         [0040]    Examples of the access network  23  are an Active Optical Network (AON)-type Fiber To The Home (FTTH) network  24 , a Passive Optical Network (PON)-type FTTH network  25 , a Wibro Network  26 , a Wireless Local Area Network (WLAN)  27 , and so forth. The AON-type FTTH network  24  may be composed of L2 switches and an L2/L3 switch, and the PON-type FTTH network  25  may be composed of a PON Optical Line Termination (OLT) and PON Optical Network Terminations (ONTs). In addition, the Wibro network  26  may be composed of an Access Route Control (ACR), a Radio Access Station (RAS), and so forth, and the WLAN  27  may be composed of an L2/L3 switch and Access Points (APs). 
         [0041]    The metro network  22  is an IP-based backbone network, and may be composed of at least one L3 switch. The core network  21  is composed of several MPLS Switches. In addition, a soft switch  50 , a server group  60 , and so forth take charge of control and application layers. The server group in charge of the application layer has a server disposed for service to be provided. It can be seen from  FIG. 2  that a Video on Demand (VOD) server, a web server, a Dynamic Host Configuration Protocol (DHCP) server, and an Authentication, Authorization, Accounting (AAA) are included in the server group  60 . 
         [0042]    An Integrated Network Control Platform (INCP)  30  is a main network of the present invention, which integrally controls and manages the above-described access network  23 , the metro network  22 , and so forth. Such an INCP  30  can interact with a core network control platform  70  to control the core network. 
         [0043]      FIG. 3  is a block diagram showing an internal configuration of a network including an INCP in accordance with an exemplary embodiment of the present invention. 
         [0044]    The INCP  30  may be composed of a Policy Rule Decision Module (PRD)  31 , a Topology/Resource Management Module (TRM)  32 , a Connection Admission Control Module (CAM)  34 , a Policy Interface Module (PIM)  33 , a Traffic Monitoring Module (TM)  35 , a Fault Management Module  36 , a Performance Management Module (PM)  37 , a Command Line Interface (CLI) module  40 , a Simple Network Management Protocol (SNMP) module  39 , a database  41 , and a core network interworking module  38 . 
         [0045]    The PRD  31  acts to determine and reflect a policy regarding control and management of the access network  23  and the metro network  22 . In particular, the PRD  31  sets a limit network resource for authenticating a call to be transmitted from a complex network. That is, it may set the limit network resource and determine the policy in a way that allows the transmitted call to be authenticated only when an available limit network resource is greater than the limit network resource. 
         [0046]    Such a PRD  31  may be composed of an access network policy module  31 A, a metro network policy module  31 B, an event policy module  31 C, and an internal policy module  31 D. 
         [0047]    The access network policy module  31 A is, in turn, composed of an AON policy module, an E/G/WDM-PON policy module, a Wibro policy module, and a WLAN policy module, and each module determines the policy of the corresponding access network. 
         [0048]    In addition, the metro network policy module  31 B includes an L2/L3 switch policy module. The event policy module  31 C may be composed of a CAM event policy module, a TRM event policy module, a TM event policy module, an FM event policy module, and a PM event policy module, which determine the policy of the event notified from the CAM  34 , the TRM  32 , the TM  35 , the FM  36 , and the PM  37 , respectively. 
         [0049]    The internal policy module  31 D delivers a policy input from an operator to the corresponding policy module in charge of the policy. For example, when a user inputs a policy for controlling the Wibro network  26 , the internal policy module  31 D serves to deliver the corresponding policy to the Wibro policy module within the access network policy module  31 A. 
         [0050]    The TRM  32  collects and manages resources of each of the access network  23  and the metro network  22 . The TRM  32  manages the network configuration according to the policy of the PRD  31 . Network topology, bandwidth, delay time, delay variance, and so forth are collectively referred to as network resources. In this case, network topology relates to network configuration shape such as bus type, star type, tree type, or ring type. 
         [0051]    The topology management module  32 B and the resource management module  32 A within the TRM  32  manage the topology and resources of the network, respectively. The TRM  32  generates and manages a virtual path between the L2/L3 switches for effective management of network resources and a Call Admission Control (CAC) function of the CAM  34 , and this path is generated and managed by the virtual path management module  32 C. Such a virtual path corresponds to a path for optimally exchanging data between heterogeneous networks. That is, the TRM  32  sets the optimal virtual path in advance, and provides optimal service using the virtual path when a link between the heterogeneous networks is required. 
         [0052]    In addition, the TRM  32  collects network resource information from components of the access network  23  and the metro access  22 , and generates a Topology/Resource (T/R) table. Such a T/R table may be a list type. The TRM  32  also updates the corresponding information whenever the network resources change. 
         [0053]    The CAM  34  takes charge of a CAC function which determines whether call set-up is allowed for a call service such as VoIP and a moving picture service such as VoD. The CAM  34  includes a soft switch interworking module  34 A and a multimedia server interworking module  34 B. These modules receive call set-up requests from the soft switch  50  and the multimedia server  60 , respectively. The CAM receiving the requests identifies the resource information on the T/R table generated in the TRM  32  via the database  41 , and then determines whether the requested call set-up requests are allowed. 
         [0054]    In particular, the CAM  34  compares the limit network resource set by the PRD  31  with the current resource identified via the database  41 , and allows the call when the network resources to be allocated for the received call are available. 
         [0055]    The PIM  33  generates a command to set the policy to be transmitted from the PRD  31  to each component of the access network  23  and the metro network  22 . The PIM  33  identifies the corresponding component to which the set policy is to be applied, and then generates a CLI command for controlling the corresponding component and an SNMP object. The PIM  33  can simultaneously apply one policy set by an operator to several components due to its CLI and SNMP characteristics. This is possible because the PIM  33  can convert the command per component with respect to one policy and transmit it. 
         [0056]    The TM  35  continuously monitor the traffic usage status, the fault management module  36  continuously manages fault occurrence and the memory of the network components, and the PM  37  continuously manages the Central Processing Unit (CPU) resource status. The CLI module  40  and the SNMP module  39  are connected to the network components, and act to collect information from the components. The operation thereof will now be described in detail. 
         [0057]    The TM  35  collects actual traffic information of each network via the traffic gathering module within the SNMP module  39  so as to identify the resource usage status of the network. In addition, the TM  35  compares the resource usage status with a theoretical network resource status managed by the TRM  32 , and notifies the PRD  31  of any problems when they occur, thereby adjusting network resource allocation. 
         [0058]    The FM  36  determines whether a fault occurs on each network via the fault discovery module within the CLI module  40  or the SNMP module  39  and the trap reception module within the SNMP module  39 , and notifies the TRM  22  and the PRD  31  of the fault information when a fault occurs. Accordingly, the TRM  32  updates the topology and resource information of the network through operations of removing components of the faulted network, notifies the operator of the fault occurrence, and determines the network fault recovery policy. 
         [0059]    The PM  37  collects performance information of each network component via the performance discovery module and the trap reception module included in the SNMP module  39 . When a problem occurs with the performance of each constitutional component, the PM  37  notifies the fault management module  36  of the event so as to have it process the fault. Accordingly, the TRM  32  upgrades the component performance, and the PRD  31  notifies the operator of the update so as to have the operator control the component. 
         [0060]    The SNMP module  39  and the CLI module  40  connect to the components of the access network  23  and the metro network  22 , exchange various information, and transmit commands for controlling the components. The SNMP  39  module uses the SNMP command along with the component name to carry out communication, and the CLI module uses the CLI command to carry out communication. 
         [0061]    The database  41  stores all data used in the INCP  30 , that is, policy information, topology and resource information, traffic information, log data, and so forth. 
         [0062]    The core network interworking module  38  interworks with the core network control platform  70 . In particular, the core network interworking module  38  processes a CAC function using the core network control platform  70  in an End to End manner. 
         [0063]    Examples of controlling and managing the network using a bandwidth will be described with reference to the above-described INCP  30 . 
         [0064]    The PRD  31  delivers a resource allocation command of each access network  23  to the PIM  33  in order to control the resources of the network according to a policy set by the operator. For example, when the link bandwidth within a specific network is 100 and the service class has four types, the operator can define a policy of allocating bandwidth per service. For example, 30%, 20%, 15%, and 10%, of the bandwidth can be allocated to the classes 0, 1, 2, and 3, respectively. The bandwidth ratios can also be varied according to the policy of the user. 
         [0065]    The PIM  33  receiving the policy, i.e., the command to allocate the bandwidth per service class from the PRD  31 , delivers the command to each constitutional component of the access network  23  and the metro network  22  so as to allow each component to modify the allocated bandwidth information. 
         [0066]    After the bandwidth allocation of the network component to be controlled is completed, the TRM  32  receives the bandwidth allocation information from the PRD  31 , or recollects the bandwidth allocation information via the CLI module  39  or the SNMP module  40 , so as to complete the T/R table of the network. The virtual path management module  32 C may also use the set bandwidth information to check the optimal virtual path between heterogeneous networks. 
         [0067]    When a new component, a new link, or the like is generated on the network, the TRM  32  notifies the PRD  31  of the generation, and the PRD  31  can control the bandwidth of the new link and the new component according to the set policy. In the same way, when the optimal virtual path is changed, it can modify and store the change again. 
         [0068]    The CAM  34  receives the call set-up request, and determines whether the call set-up request is allowed according to an extra bandwidth resource. When the received call set-up request is frequently rejected, the CAM  34  can notify the event policy module  31 C within the PRD  31  of the rejection information, and can increase the bandwidth of the class where the call belongs to cope with the rejection. Each constitutional component and detailed operations of the INCP  30  will be described below. 
         [0069]      FIG. 4  is a flowchart showing the operation of a PRD in accordance with another exemplary embodiment of the present invention. 
         [0070]    The PRD  31  first determines a policy for controlling components of the access network  23  or the metro network  22  according to a policy inputted by an operator. 
         [0071]    The operator inputs the network operation policy via the operator interface  42  (S 401 ). The input policy is stored in the database  41  (S 402 ) and is simultaneously delivered to the PRD (S 403 ). The PRD delivers the input policy to the PIM  33  (S 404 ). The PIM  33  uses the database  41  to retrieve variables and corresponding components for carrying out the policy (S 405 ), and generates the corresponding commands (S 406 ). In this case, the commands are generated using the CLI or the SNMP MIB. The generated commands are transmitted to the SNMP module  39  or the CLI module  40  (S 407 ), which in turn deliver the commands to the components of the access network  23  and the metro network  22  (S 408 ). The SNMP module  39  or the CLI module  40  delivers the processed result of the policy to the operator interface  42  via the PIM  33  and the PRD  31  (S 409  to S 411 ). When a fault occurs during a procedure of setting the policy, the operator can identify the cause of the fault and retry setting the policy (S 412 ). Such delivered commands allow the policy input by the operator to be applied to each constitutional component of the network. 
         [0072]    In addition, the PRD  31  acts to control and manage the internal modules of the INCP  30  according to the policy of the operator. 
         [0073]    The operator uses the operator interface  42  to set the internal policy for controlling the internal modules of the INCP  30  (S 413 ). The internal policy is stored in the database  41  (S 414 ), and is also delivered to the PRD  31  (S 415 ). The SNMP and CLI commands do not need to be generated during a procedure of setting the internal policy, so that the PRD  31  directly retrieves the variables and corresponding components for carrying out the policy from the database  41  (S 416 ). The PRD  31  delivers the policy to the corresponding retrieved component (S 417 ). For example, the PRD  31  may transmit the policy to the CAM  34 , the TRM  32 , the TM  35 , the fault management module  36 , the PM  37 , and so forth (S 417 A to S 417 E). The network policy does not need to be transmitted to all modules, and can be transmitted only to modules where it is to be applied. 
         [0074]      FIG. 5  is a flowchart showing the operation of a TRM in accordance with still another exemplary embodiment of the present invention. 
         [0075]    Operations of the TRM  32  are mainly classified into generation and update of the T/R table, and generation and update of the virtual path. 
         [0076]    As can be seen in  FIG. 4 , the PRD  31  carries out the procedure of setting the policy with respect to the components of the network (S 401  to S 408 ). In this case, the SNMP module  39  or the CLI module  40  carries out step S 409 , collects the network topology and resource information from the components of the access network  23  and the metro network  22  (S 501 ), and delivers them to the TRM  32  (S 502 ). The TRM  32  uses the collected network topology and resource information to generate the T/R table (S 503 ). Such a generated T/R table can be stored in the database  41  (S 504 ). 
         [0077]    When a fault occurs in a component of the access network  23  and the metro network  22 , the fault occurrence information is transmitted to the operator interface  42  via the SNMP module  39 /CLI module  40 , the TRM  32 , and the PRD  31  (S 505 ). In this case, the TRM  31  updates the T/R table to reflect the fault occurrence information (S 506 ). The TRM  32  stores the updated T/R table in the database (S 507 ). When the fault occurs, the TRM  32  carries out steps S 505  to S 507 , and the PRD  31  carries out step S 412 . 
         [0078]    In addition, the SNMP module  39  or the CLI module  40  collects the IP routing table from the components of the access network  23  and the metro network  22  (S 508 ), and transmits the collection to the TRM  32  (S 509 ). The TRM  32  uses the IP routing table to generate a virtual path (S 510 ), and stores it in the database  41  (S 511 ). The virtual path corresponds to path information for optimally exchanging data between complex networks. When the IP routing table on the network is changed (S 512 ), the SNMP module  39  and the CLI module  40  recollect the changed IP routing table (S 513 ), and deliver the changed IP routing table to the TRM  32  (S 514 ). The TRM  32  uses the recollected IP routing table to modify the virtual path (S 515 ), and stores the updated virtual path in the database  41  (S 516 ). In addition, the TRM  32  notifies the CAM  34 , using the virtual path, that is not updated with the virtual path update (S 517 ). 
         [0079]      FIG. 6  is a flowchart showing the operation of a CAM in accordance with yet another exemplary embodiment of the present invention. 
         [0080]    The call server or the multimedia server delivers a CAC request to the CAM  34  (S 601 ). The CAM  34  queries the database  41  about resources of the access network  23  where the call needs to be set (S 602 ). The database  41  retrieves the stored resources of the access network  23  (S 603 ), and responds to the CAM  34  with the retrieved result (S 604 ). When the access network  23  lacks the necessary resources, it delivers a busy signal to the call server or the multimedia server transmitting the CAC request (S 605 ). 
         [0081]    When the resources of the access network are present, the CAM  34  requests the TRM  32  to inquire about the virtual path (S 606 ). The TRM  32  inquires about the virtual path (S 607 ), and responds to the CAM  34  with the result (S 608 ). Accordingly, it can be found through which components of the metro network packets are optimally transmitted using the virtual path. 
         [0082]    Subsequently, resources should be checked to identify whether the optimal virtual path found in steps S 606  to S 608  can be used. The CAM  34  retrieves the resources of the metro network  22  according to the virtual path. The retrieved resources are displayed using the virtual path (VR)-based metro network resource inquiry. Steps of retrieving the resources of the metro network  22  (S 609  to S 611 ) are almost the same as steps S 602  to S 604 , and thus a description thereof will be omitted. 
         [0083]    The CAM  34  transmits the resource status of the metro network to the soft switch or the multimedia server (S 612 ). In detail, the CAM returns a busy signal when the metro network lacks sufficient resources, and returns an OK signal when metro network has sufficient resources. When the OK signal is returned, the soft switch or the multimedia server links a new call, so that the topology and the resource status of the network will be changed. Accordingly, the CAM  34  issues a command to update the resources to the database  41  (S 613 ), and the database  41  updates the change in resource status of the network according to the new call set-up (S 614 ). 
         [0084]    When the optimal virtual path is changed in step S 614 , the TRM  32  determines the optimal virtual path again, and delivers the determination result to the CAM  34  (S 615 ). In this case, the CAM  34  pauses the call processing step (S 616 ), and delivers the changed virtual path information to the database  41  (S 617 ). The database  41  updates the resource status according to the changed virtual path information (S 618 ), and then the CAM  34  resumes the paused call processing step (S 619 ). These steps allow the call between the multimedia server and the receiving terminal to be set. 
         [0085]    When the new call is set, it may exceed the call setting ratio threshold of the network. When such a situation occurs, the CAM  34  notifies the operator of the exceeded call block ratio threshold using the user interface  41  (S 620 ). 
         [0086]    The CAM  34  also notifies the TM that the new call is set (that is, the CAC-based network resource status is changed) (S 621 ). 
         [0087]      FIG. 7  is a flowchart showing the operation of a TM in accordance with another exemplary embodiment of the present invention. 
         [0088]    As in the case of  FIG. 5 , the SNMP module  39  or the CLI module  40  periodically communicates with the components of the access network  23  or the metro network  22  to collect network resource usage status information (S 701 ). The network resource status information collected is transmitted to the TM  35  (S 702 ). The TM  35  can store the collected network resource usage status information in the database  41  (S 703 ), and can provide it to the operator (S 704 ) using the operator interface  42 . Accordingly, the operator can monitor the traffic status of each network (S 705 ). The TM  35  analyzes the network resource status (S 706 ), and when the traffic of the network being used exceeds a traffic threshold, TM  35  notifies the PRD  31  and the operator interface  42  (S 707 ). 
         [0089]    When the TM  35  is notified of a change in CAC-based network resource status by the CAM  34  according to step S 621  of  FIG. 6  (S 708 ), the TM  35  compares the traffic information collected in real time with the changed network resource information (S 709 ). Such steps are carried out by a method similar to that of step S 706 . In the same way, when the resources being used exceed the threshold notified by the CAM  34 , the TM notifies the PRD  31  and the operator interface  42 . 
         [0090]      FIG. 8  is a flowchart showing the operation performed when an event of a PRD is generated in accordance with yet another exemplary embodiment of the present invention. 
         [0091]    When the PRD  31  is first notified of a network fault by the TRM  32  (S 801 ), the PRD  31  uses the operator interface  42  to display the fault occurrence status (S 802 ), and receives the corresponding policy from the operator (S 803 ). The input policy is stored in the database  41  (S 804 ), and is simultaneously transmitted to the PIM  33  (S 805 ). The PIM  33  retrieves the variables or the target for carrying out the policy from the database  41  (S 806 ), and generates a command for setting the policy (S 807 ). The command may also be generated using the CLI or the SNMP MIB. The generated command is delivered to components of the access network  23  or the metro network  22  via the SNMP module  30  and the CLI module  40  (S 808 ). In addition, the SNMP module  39  and the CLI module  40  collect the set result of the policy from the components, and deliver it to the PIM  33 , the PRD  31 , and the operator interface  41  (S 809  and S 810 ). When a fault occurs in the step of setting the policy, the operator identifies the cause and re-inputs a modified policy (S 811 ), and the step of setting the policy is performed again in the same manner as described above. After the policy is set, the PRD  31  notifies the TRM  32  of the result of processing the network fault (S 812 ). 
         [0092]    Subsequently, when the PRD  31  is notified of the exceeding of the call block ratio threshold by the CAM  34  in step S 620  of  FIG. 6 , the PRD  31  has the operator interface  42  display the event (S 813 ). Accordingly, the operator generates and inputs the policy for coping with the event. Steps S 814  to S 817  for the policy are similar to steps S 803  to S 806 . However, the CAM  34  is an internal module of the INCP  30 , and thus the input policy does not pass through the SNMP module  39  and the CLI module  40 , but is directly delivered to the CAM  34 . The CAM  34  is notified of the result of processing of the fault as in steps S 813  to S 817  described above (S 818 ). 
         [0093]    When the PRD  31  is notified of the exceeding of the threshold by the TIM  35  in step S 701  (S 819 ), the PRD  31  uses the same method as described in steps S 803  to S 812  to manage the components of the access network  23  and the metro network  22 . 
         [0094]      FIG. 9A  is a block diagram showing the configuration of a network for a VoIP call between a PON user and a Wibro user in accordance with yet another exemplary embodiment of the present invention, while  FIG. 9B  is a flowchart showing the operation of the complex network control system of  FIG. 9A . 
         [0095]    As shown in  FIG. 9A , the first subscriber terminal  70  using the PON and the second subscriber terminal  80  using the Wibro network have a VoIP call via the PON  25  as the access network, the IP-based metro network  22 , and the Wibro network  26 . 
         [0096]    In this case, the INCP  30  controls the PON EMS included in the PON  25 , the Wibro EMS included in the Wibro network  26 , the L3 switch of the metro network  22 , and so forth. Control operations of the INCP  30  will be described below with reference to  FIG. 9B . 
         [0097]    The first subscriber terminal  70  of the user on the PON makes a call set-up request. The call set-up request of the first subscriber terminal  70  is first transmitted to the call server or the multimedia server via the PON  25  (S 901 ). The call server or the multimedia server receiving the call set-up request requests the CAM  34  of the INCP  30  to authenticate the call (S 902 ). 
         [0098]    The CAM  34  requests the database  41  to check the resources of the access network (S 903 ). In this regard, the CAM  34  can make the request merely by delivering, to the database  41 , the information of the access network  23  to which the first subscriber terminal  70  and second subscriber terminal  80  belong and the network resources list to be checked. In the present embodiment, the CAM  34  requests the database to check resources with respect to the Logical Link Identifier (LLID) bandwidth of the E-PON  25  and the Channel Identifier (CID) bandwidth of the Wibro network  26 . The database  41  retrieves the stored access network resources (S 904 ), and reports the result to the CAM  34  (S 905 ). It can be seen that the database  41  transmits the response that the resources are present to the CAM  34  in the present embodiment. The CAM  34  in turn requests the TRM  32  to inquire about the virtual path (S 906 ). The TRM  32  inquires about the virtual path, which is the optimal transmission path between the PON  25  and the Wibro network  26  (S 907 ), and reports the result to the CAM  34  (S 908 ). 
         [0099]    When the CAM  34  needs to carry out communication on the virtual path, it requests the resources of the metro network  22  through which the communication is carried out (S 909 ). In the same way, the database  41  retrieves the resources of the metro network (S 910 ), and transmits the response that the resources are present to the CAM  34  (S 911 ). 
         [0100]    Resources of the PON  25 , the Wibro network  26 , and the metro network  22  are sufficient, and thus the CAM  34  transmits the response message that sufficient resources are present to the call server or the multimedia server (S 912 ). The CAM  34  also issues to the database  41  a command to update the resource status information (S 913 ), and the database  41  in turn updates the resource status (S 914 ). In this case, when the network resources are insufficient, the INCP  30  can reset the policy with respect to the network having insufficient resources so as to allow the CAC. For example, when the network resources are insufficient, there may be a policy that changes the bandwidth allocated to each service class so as to obtain sufficient bandwidth for the VoIP call. 
         [0101]    The call server or the multimedia server transmits a call admission message, including the address information of the second subscriber terminal  80 , to the first subscriber terminal  70  (S 915 ). The first subscriber terminal  70  uses the call admission message to set up a call with the second subscriber terminal  80  on the Wibro network  26  so that the VoIP call is carried out (S 916 ). 
         [0102]    When the VoIP call is terminated, the first subscriber terminal  70  transmits a Call End Request to the call server or the multimedia server (S 917 ). The call server or the multimedia server notifies the second subscriber terminal  80  of the call termination (S 918 ). The call server receiving the response with respect to the call termination from the second subscriber terminal  80  notifies the first subscriber terminal  70  of the call release (S 920 ). The call server also notifies the CAM  34  of the call release between the first subscriber terminal  70  and second subscriber terminal  80  (S 921 ), the CAM  34  issues to the database  41  a command to update the resources (S 922 ), and the database  41  updates the resources (S 923 ). 
         [0103]    As described above, according to the system and method for controlling and managing heterogeneous networks, i.e., an access network and a metro network, of the present invention, resource status and performance status of the access network and the metro network can be continuously controlled and managed so that a high-quality and large-capacity service QoS can be provided to users, and seamless QoS can be guaranteed for communication between heterogeneous networks. 
         [0104]    While the present invention has been described with reference to exemplary embodiments thereof, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the present invention as defined by the following claims.