Abstract:
Methods, systems, and computer program products for a hierarchical, redundant OAM&amp;P architecture for use in an IP multimedia subsystem (IMS) are disclosed. According to one aspect, the subject matter described herein includes a system for managing an Internet protocol multimedia system (IMS) network. The system includes a network operations, administration, maintenance, and provisioning (OAM&amp;P) entity for communicating with an operator&#39;s network, a system OAM&amp;P entity associated with the network OAM&amp;P entity, and at least one message processing entity associated with the system OAM&amp;P entity for processing signaling information and for implementing at least one application. The system OAM&amp;P entity receives OAM&amp;P information from one or more message processing entities and communicates at least some of the received OAM&amp;P information to the network OAM&amp;P entity. The network OAM&amp;P entity receives OAM&amp;P information from the system OAM&amp;P entity and communicates at least some of the received OAM&amp;P information to the operator&#39;s network.

Description:
RELATED APPLICATIONS 
     This application claims the benefit of U.S. Provisional Patent Application Ser. No. 60/834,577 filed Jul. 31, 2006; the disclosure of which is incorporated herein by reference in its entirety. 
    
    
     TECHNICAL FIELD 
     The subject matter described herein relates to methods and systems for use in an Internet protocol (IP) multimedia subsystem (IMS). More particularly, the subject matter described herein relates to methods, systems, and computer program products for implementing a hierarchical, redundant operations, administration, maintenance, and provisioning (OAM&amp;P) architecture for managing an IMS network. 
     BACKGROUND 
     IMS is defined by the Third Generation Partnership Project (3GPP) as a new mobile network infrastructure that enables the convergence of data, speech, and mobile network technology over an IP-based infrastructure. IMS bridges the gap between the existing traditional telecommunications technology and Internet technology, allowing network operators to offer a standardized, reusable platform that can be used to provide services for both mobile networks and landline networks at the same time, providing unique mixtures of services with transparency to the end-user. 
     The main function of IMS is to set up media communication sessions between users and between users and applications. IMS uses the session initiation protocol (SIP) to for initiating, modifying, and terminating an interactive user session that involves multimedia elements, such as video, voice, instant messaging, online games, and virtual reality, and provides the service creator the ability to combine services in the same session and dynamically modify sessions “on the fly” (e.g., adding a video component to an existing voice session). As a result, new and innovative user-to-user and multi-user services become available, such as enhanced voice services, video telephony, chat, push-to-talk, and multimedia conferencing, all of which are based on the concept of a multimedia session. 
     As used herein, the term “IMS network” refers to a collection of connected entities performing IMS and other types of functions. An IMS network may be controlled by an operator, which is typically a business entity, such as a telephone company. The set of IMS entities within a particular operator&#39;s control may be referred to as an operator&#39;s network. The operator may control the operator&#39;s network from a network operations center (NOC) or other network control entity. 
     As used herein, the term “subscriber” refers to an operator&#39;s customer who uses the operator&#39;s network. Typically, all of an operator&#39;s subscribers are assigned to the operator&#39;s network. A subset of subscribers in an operator&#39;s network is referred to as a point of presence (POP). 
     As used herein, the term “IMS network element” (NE) refers to a logical grouping of entities that perform a specific assigned IMS or other function or group of functions within an IMS network. 
     As used herein, the term “node” refers to the portion of a network element on which an IMS, OAM&amp;P, or other type of function resides. 
     IMS functions may include the call session control function (CSCF), the home subscriber server (HSS) function, and the authentication, authorization, and accounting (AAA) function. Non-IMS functions that may be present in an IMS network include application server (AS) functions. 
     The CSCF is used to process SIP signaling packets in the IMS. It aids in the setup and management of sessions and forwards messages between IMS networks. There are three distinct CSCF functions: proxy CSCF (P-CSCF, or “P-node”), interrogation CSCF (I-CSCF, or “I-node”), and serving CSCF (S-CSCF, or “S-node”). The P-CSCF is the first point of contact for a subscriber connecting to the network; it is the gateway into the IMS network. The P-CSCF implements compression and security. A P-CSCF may be configured to forward requests to a specific I-CSCF, which is the next node in the IMS signaling path. The I-CSCF provides a subscriber location function (SLF), which maps a subscriber to a specific S-CSCF, thus enabling the I-CSCF to route requests to the correct S-CSCF. The I-CSCF also provides a network interconnect function (NIF). The NIF knows how to route requests to other interconnecting networks (via their I-CSCFs). The S-CSCF is the core of the network. The S-CSCF maintains a database for all of the subscribers assigned to a POP. The S-CSCF provides services for the users, such as setting up media communication sessions between users and applications. 
     The HSS function holds key subscriber information and enables users (or servers) to find and communicate with other end users. 
     The AAA function authenticates the user, gives access only to valid users, grants the user authority to use certain functions or features available on the IMS network, and tracks user activity for accounting and billing purposes. 
     As stated above, other functions that may be present in an IMS network include non-IMS functions, such as those collectively referred to as application server (AS) functions. AS functions may include prepaid services, presence services, E.164 number translation (ENUM) services, location-based services, number portability services, message services (e.g., short message service (SMS), multi-media messaging, instant messaging), billing applications, network monitoring applications, call control services (e.g., call waiting, call holding, call forwarding, call transfer, call blocking), conference call services, announcement services, push-to-talk services, voicemail services, text to speech and speech to text services, law-enforcement-related services (e.g., malicious caller identification, lawful interception), and 2-G gateway services. 
     In an IMS network, each application or function may generate measurement data, event data, alarm data, and log data, collectively known as “MEAL” data, during operation of the function. An IMS or other function may also create entities known as stateful managed objects, which are abstract representations of network resources that are managed. A managed object may represent a physical entity, a network service, or an abstraction of a resource that exists independently of its use in management. The stateful managed object data is known as “SMOD” data. MEAL and SMOD data may be used by the NOC to monitor the status and operation of the operator&#39;s network. 
     In an IMS network, an application or function may accept configuration and provisioning commands as input. Configuration and provisioning commands may, for example, alter the state of a service, change the capability of an entity, create, maintain, or deactivate subscribers and subscriber attributes, and configure or customize the IMS system or operator&#39;s network. The NOC may control the operator&#39;s network by issuing configuration and provisioning commands that modify the function or operation of entities within the operator&#39;s network. 
     The network monitoring and control functions are often collectively referred to as “operations, administration, maintenance, and provisioning”, or OAM&amp;P, functions. 
     Operations functions may include automatic monitoring of environment, detecting and determining faults and alerting network administrators (e.g. using alarm data). 
     Administration functions typically involve collecting performance statistics (e.g. log data), collecting accounting data for the purpose of billing (e.g. events data), planning for capacity using usage data (e.g. measurements data), and maintaining system reliability. Administration functions can also involve maintaining the service databases which are used to determine periodic billing. 
     Maintenance functions typically involve upgrades, fixes, new feature enablement, backup and restore, and monitoring the media health (e.g. configuration data). The major tasks of maintenance functions are diagnostics and troubleshooting. 
     Provisioning functions typically handle the setting up of the user accounts, devices and services (e.g. provisioning data). 
     OAM&amp;P functions are typically handled by an OAM&amp;P entity, such as a server. A conventional IMS network may be configured such that one OAM&amp;P server handles OAM&amp;P functions for P-nodes, another OAM&amp;P server handles OAM&amp;P functions for I-nodes, and yet another OAM&amp;P server handles OAM&amp;P functions for S-nodes. 
     There are disadvantages associated with a conventional IMS network as described above. One disadvantage is that a network element containing more than one IMS function or other application may require more than one OAM&amp;P server—one for each IMS function or application supported. Another disadvantage is that the NOC may need to communicate with several OAM&amp;P servers within the operator&#39;s network. 
     Accordingly, in light of these disadvantages associated with IMS networks, there exists a need for improved OAM&amp;P architecture for use in an IMS network. 
     SUMMARY 
     According to one aspect, the subject matter described herein includes a system for managing an Internet protocol multimedia system (IMS) network. The system includes a network operations, administration, maintenance, and provisioning (OAM&amp;P) entity for communicating with an operator&#39;s network, a system OAM&amp;P entity associated with the network OAM&amp;P entity, and at least one message processing entity associated with the system OAM&amp;P entity for processing signaling information and for implementing at least one application. The system OAM&amp;P entity receives OAM&amp;P information from one or more message processing entities and communicates at least some of the received OAM&amp;P information to the network OAM&amp;P entity. The network OAM&amp;P entity receives OAM&amp;P information from the system OAM&amp;P entity and communicates at least some of the received OAM&amp;P information to the operator&#39;s network. 
     According to another aspect, the subject matter described herein includes a method for managing an IMS network. The method includes performing a message processing function, including processing signaling information, performing at least one application function, and generating operations, administration, maintenance, and provisioning (OAM&amp;P) information; performing a system OAM&amp;P function including receiving at least some of the OAM&amp;P information from the message processing function; and performing a network OAM&amp;P function including receiving at least some of the OAM&amp;P information from the system OAM&amp;P function and communicating at least some of the OAM&amp;P information to an operator&#39;s network. 
     According to yet another aspect, the subject matter described herein includes a method for remotely configuring an IMS entity. The method includes detecting the presence of a configurable IMS entity at a system operations, administration, maintenance, and provisioning (OAM&amp;P) entity, communicating the detection to a network OAM&amp;P entity, receiving configuration data from the operator at the network OAM&amp;P entity, and communicating the configuration data to the system OAM&amp;P entity, where the system OAM&amp;P entity configures the configurable IMS entity based on the configuration data. 
     The subject matter described herein for managing an IMS network may be implemented in software in combination with hardware and/or firmware. For example, the subject matter described herein can be implemented in software executed by a processor. As such, the terms “entity” or “module” as used herein refer to software in combination with hardware and/or firmware, for implementing the feature being described. In one exemplary implementation, the subject matter described herein may be implemented using a computer program product comprising computer executable instructions embodied in a non-transitory computer readable medium. Exemplary computer readable media suitable for implementing the subject matter described herein include disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer program product that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Preferred embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings of which: 
         FIG. 1  is a block diagram illustrating an exemplary hierarchical operation, administration, maintenance, and provisioning (OAM&amp;P) architecture for use in an Internet protocol multimedia subsystem (IMS) according to an embodiment of the subject matter described herein; 
         FIG. 2  is a block diagram illustrating an exemplary redundant OAM&amp;P network element according to an embodiment of the subject matter described herein; 
         FIG. 3  is a block diagram illustrating an exemplary redundant signaling network element according to an embodiment of the subject matter described herein; 
         FIG. 4  is a block diagram illustrating an exemplary message processing entity within a hierarchical OAM&amp;P architecture according to an embodiment of the subject matter described herein; 
         FIG. 5  is a flow chart illustrating a method for managing an Internet protocol multimedia subsystem (IMS) according to an embodiment of the subject matter described herein; and 
         FIG. 6  is a flow chart illustrating a method for remotely configuring an Internet protocol multimedia subsystem (IMS) entity according to an embodiment of the subject matter described herein. 
     
    
    
     DETAILED DESCRIPTION 
     In order to avoid the necessity that an IMS network element providing more than one type of IMS function or other application contain a separate OAM&amp;P server for each type of IMS function or application and to avoid the disadvantages associated with the need for the NOC to communicate with multiple OAM&amp;P servers, the subject matter described herein includes a hierarchical, redundant OAM&amp;P architecture for managing an IMS network. The system includes an IMS network, which is made up of one or more signaling network elements, each of which contains a system OAM&amp;P entity for collecting and aggregating OAM&amp;P information associated with that signaling network element; a central network operations center (NOC), from which the IMS network is controlled; and an OAM&amp;P network element, which acts as the gateway for OAM&amp;P information being communicated between the NOC and the IMS network. 
       FIG. 1  is a block diagram of an exemplary hierarchical, redundant IMS network management system in accordance with an embodiment of the subject matter described herein. In  FIG. 1 , IMS network  100  includes a network operations center  102  controlling an operator&#39;s network  104  via a connection through operator&#39;s management network (also known as the external management interface, hereinafter referred to as XMI  106 ) to OAM&amp;P network element  108 . OAM&amp;P network element  108  may include network OAM&amp;P entity  110 . Network OAM&amp;P entity  110  may communicate via internal management network (also known as the internal management interface, hereinafter referred to as IMI  112 ) with one or more instances of signaling network element  114 . Each signaling network element  114  may include system OAM&amp;P entity  116 , and one or more instances of message processing entity  118 . 
     Network OAM&amp;P entity  110  may aggregate OAM&amp;P data, such as MEAL and SMOD data, from one or more instances of system OAM&amp;P entity  116 . The aggregated data may include OAM&amp;P data associated with multiple types of applications  120  within operator&#39;s network  104 . Network OAM&amp;P entity  110  may send the aggregated data to network operations center  102 . OAM&amp;P data may for example be sent continuously, periodically, or as needed by network OAM&amp;P entity  110 . Alternatively, the OAM&amp;P data may be sent in response to a request received from network operations center  102 . Network OAM&amp;P entity  110  may store data in preparation for communication with network operations center  102 , allowing network OAM&amp;P entity  110  to operate without requiring a continuous network connection to network operations center  102  or to continue operating when the connection to network operations center  102  is lost or otherwise interrupted. Network OAM&amp;P entity  110  may receive from network operations center  102  configuration and provisioning data which network OAM&amp;P entity  110  may use to modify its own operation or may forward to system OAM&amp;P entity  116 . 
     System OAM&amp;P entity  116  may process OAM&amp;P information received from one or more instances of message processing entity  118  and communicate the OAM&amp;P information to network OAM&amp;P entity  110 . System OAM&amp;P entity  116  may aggregate OAM&amp;P data, such as MEAL and SMOD data, from one or more instances of message processing entity  118 , multiple applications  120  and multiple types of applications  120  within signaling network element  114 , and send the aggregated data to network OAM&amp;P entity  110 . Applications  120  may be IMS functions, such as P-CSCF, I-CSCF, S-CSCF, HSS, and AAA, or non-IMS functions, such as application server (AS) functions. Applications  120  typically generate MEAL and SMOD data and receive and use configuration and provisioning data. One or more instances of message processing entity  118  may communicate this OAM&amp;P information with system OAM&amp;P entity  116 . Message processing entity  118  may communicate some types of OAM&amp;P information, such as fault conditions, directly to network OAM&amp;P entity  110  or to network operations center  102 . 
     OAM&amp;P data may for example be sent continuously, periodically, or as needed by system OAM&amp;P entity  116 , or sent in response to a request received from network OAM&amp;P entity  110 . System OAM&amp;P entity  116  may store data in preparation for communication with network OAM&amp;P entity  110 , allowing system OAM&amp;P entity  116  to operate without requiring a continuous network connection to network OAM&amp;P entity  110 , or to continue to operate when the connection to network OAM&amp;P entity  110  is lost or otherwise interrupted. System OAM&amp;P entity  116  may receive from network OAM&amp;P entity  110  configuration and provisioning data which system OAM&amp;P entity  116  may use to modify its own operation or may forward to message processing entity  118 . 
     Message processing entity  118  may include one or more applications  120  and may process signaling information received through operator&#39;s signaling network (also known as the signaling interface, hereinafter referred to as SIGI  122 ). Message processing entity  118  may be a server, a cluster of processors, a processor card in a rack, or a software component, for example. Message processing entity  118  may aggregate OAM&amp;P data, such as MEAL and SMOD data, from multiple applications  120  and multiple types of applications  120  within message processing entity  118 , and send the aggregated data to system OAM&amp;P entity  116 . OAM&amp;P data may for example be sent continuously, periodically, or as needed by message processing entity  118 . Alternatively, OAM&amp;P information may be sent in response to a request received from system OAM&amp;P entity  116 . Message processing entity  118  may store data in preparation for communication with system OAM&amp;P entity  116 , allowing message processing entity  118  to operate without requiring a continuous network connection to system OAM&amp;P entity  116  or to continue to operate when the connection to system OAM&amp;P entity  116  is lost or otherwise interrupted. Message processing entity  118  may receive from system OAM&amp;P entity  116  configuration and provisioning data which message processing entity  118  may use to activate, deactivate, or modify applications  120 . 
     In one embodiment, OAM&amp;P network element  108  may include one or more instances of network OAM&amp;P entity  110  for communicating OAM&amp;P data with network operations center  102 ; for example, using multiple network OAM&amp;P servers operating in a manner so as to allow load-sharing. 
     In another embodiment, signaling network element  114  may include one or more instances of system OAM&amp;P entity  116  for communicating OAM&amp;P data with network OAM&amp;P entity  110 ; for example, using multiple system OAM&amp;P servers operating in a manner so as to allow load-sharing. 
     In yet another embodiment, signaling network element  114  may include one or more instances of message processing entity  118  for communicating OAM&amp;P data with system OAM&amp;P entity  116 ; for example, using multiple message processing servers operating in a manner so as to allow load-sharing. 
     In yet another embodiment, message processing entity  118  may include multiple instances of the same application, different applications, or different variants of an application. For example, message processing entity  118  may include multiple instances of a P-CSCF application, or a mix of P-CSCF, I-CSCF, and S-CSCF applications. In yet another embodiment, message processing entity  118  may perform multiple instances of the same non-IMS function, different non-IMS functions, or different variants of a non-IMS function. For example, message processing entity  118  may perform multiple instant message services, or an ENUM service and a presence service, a variety of law-enforcement-related services. In other embodiments, message processing entity  118  may perform IMS functions, non-IMS functions, or a combination of IMS functions and non-IMS functions. For example, message processing entity  118  may perform voicemail services, an AAA function, or both. 
     In yet another embodiment, message processing entity  118  may be preconfigured to implement multiple applications  120 , each of which may perform a different function or variants of a function. Message processing entity  118  may accept configuration commands by which message processing entity  118  activates a selected subset of preconfigured applications  120 . Message processing entity  118  may also generate a status message indicating what applications  120  it is capable of implementing. The status message may be generated in response to activation of message processing entity  118 . For a message processing entity implemented as a server, for example, activation (and subsequent generation of the status message) may be triggered by insertion of a server card into a frame, physical connection of a server into a network, logical activation of the server, providing power to the server, resetting the server, rebooting the server, or other triggering event. Any or all of the associated system OAM&amp;P entity  116 , the associated network OAM&amp;P entity  110 , or network operations center  102  may be configured to automatically detect the status message generated by message processing entity  118  and respond by sending to message processing entity  118  configuration commands which configure message processing entity  118  to, for example, perform a selected subset of applications  120  supported by message processing entity  118 . Network OAM&amp;P entity  110  may be configured to detect the status message generated by message processing entity  118  and in response alert network operations center  102  to the presence of the configurable message processing entity  118 , provide an operator with options to configure the configurable message processing entity  118 , receive the configuration selection from the operator, and forward the configuration selection to system OAM&amp;P entity  116 , which then configures message processing entity  118  according to the operator&#39;s selection. For an embodiment in which message processing entity  118  is preconfigured with multiple applications  120 , the activation, deactivation, or modification of the operation of supported applications  120  does not require that the desired applications  120  be loaded or transferred into message processing entity  118 , and thus configuration may be performed without taking the time or bandwidth required to download and install the desired applications  120 . Configuration may be performed by setting a bit in a status register or sending a short command, for example. 
       FIG. 2  is a block diagram of an exemplary OAM&amp;P network element  108  in accordance with an embodiment of the subject matter described herein. In  FIG. 2 , OAM&amp;P network element  108  includes an active instance  110  of network OAM&amp;P entity and at least one standby instance  110 A of network OAM&amp;P entity adapted to become active in response to detection of a failure or deactivation of active network OAM&amp;P entity  110 . Active network OAM&amp;P entity  110  may include an admin server  200  which may communicate with network operations center  102  via XMI  106 . According to one embodiment, XMI  106  may provide a graphical user interface, or GUI, which is the primary interface that administrators and operators may use to interact with and control OAM&amp;P network element  108 . The GUI may provide functions available for user administration, provisioning, configuration, database management, fault management, and upgrade. XMI  106  may also provide a provisioning interface, used to provision subscriber data, a fault monitoring interface, used to trap alarms and events in the system, and a remote console interface. The remote console interface may use the secure shell (SSH) protocol and may be used to perform debugging and some installation and upgrade procedures. 
     Admin server  200  may handle all incoming requests from the GUI and provisioning interfaces and return responses to those requests. In addition, admin server  200  may autonomously display data, such as current alarm configuration, current measurements, or current logs, as configured by the user. According to one embodiment, admin server  200  may access aggregate stateful managed object data (SMOD) databases  202  via SMOD client  204 , aggregate measurements, events, alarms, and logs (MEAL) databases  206  via MEAL client  208 , and configuration and provisioning databases  210  via DB client  212 . 
     Managed objects (MO) manager  214  is an interface through which changes to managed object states may be recorded. MO manager  214  may operate locally on network OAM&amp;P entity  110  and may write each change record to local SMOD databases  216 . Periodically, SMOD server  218  on active network OAM&amp;P entity  110  may ask local SMOD client  220  to pull all of the entries from local SMOD databases  216  for collection in aggregate network SMOD databases  202 . 
     Alarm and event manager  222  is an interface through which alarms and events may be generated. Alarm and event manager  222  may operate locally on network OAM&amp;P entity  110  and may generate SNMP traps corresponding to the alarms and events detected. Alarm and event manager  222  may send the SNMP traps via the fault monitoring interface component of XMI  106  to a northbound fault management system in network operations center  102 , if configured. Alarm and event manager  222  may be one of the local managers for MEAL data. As active network OAM&amp;P entity  110  updates alarms and events locally, alarm and event manager  222  may update the local MEAL databases  224  with the requested change and may write the change to network MEAL databases  206 . Periodically, MEAL server  226  on active network OAM&amp;P entity  110  may ask local MEAL client  228  to pull the latest entries from local MEAL databases  224  for collection in aggregate network MEAL databases  206 . 
     Measurement manager  230  is an interface through which measurements may be generated; it may operate locally on network OAM&amp;P entity  110  and may write a change to local MEAL databases  224 . Periodically, MEAL server  226  on active network OAM&amp;P entity  110  may ask local MEAL client  228  to pull the latest entries from local MEAL databases  224  for collection in aggregate network MEAL databases  206 . 
     Logging manager  232  is an interface through which log entries may be generated. Logging manager  232  may operate locally on network OAM&amp;P entity  110  and may write each entry to local MEAL databases  224 . Periodically, MEAL server  226  on active network OAM&amp;P entity  110  may ask local MEAL client  228  to pull the latest entries from local MEAL databases  224  for collection in aggregate network MEAL databases  206 . 
     Configuration and provisioning databases  210  contain configuration and provisioning information and may also be accessed by DB server  234 . The responsibilities of DB server  234  may include replication of configuration and provisioning information into the standby instance of network OAM&amp;P entity  110 A and into signaling network element  114 , and communication of configuration or provisioning messages to signaling network element  114 . 
     In the example illustrated in  FIG. 2 , standby network OAM&amp;P entity  110 A is assumed to be configured as an identical copy of active network OAM&amp;P entity  110 . The role of standby network OAM&amp;P entity  110 A is to be ready to provide OAM functions and provisioning functions for the entire network, in the event that active network OAM&amp;P entity  110  fails or is otherwise deactivated. This means that standby network OAM&amp;P entity  110 A may keep up with all user, administration, provisioning, configuration, database management, fault management, and upgrade changes made by active network OAM&amp;P entity  110 , but standby network OAM&amp;P entity  110 A does not provide these functions. In standby network OAM&amp;P entity  110 A, configuration and provisioning databases  210 , DB client  212 , MO manager  214 , local SMOD databases  216 , alarm and event manager  222 , local MEAL databases  224 , measurement manager  230 , and logging manager  232 , may function and operate the same as do their counterparts in active network OAM&amp;P entity  110 . However, in standby network OAM&amp;P entity  110 A, SMOD and MEAL data may be aggregated into the SMOD and MEAL databases on active network OAM&amp;P entity  110  rather than on standby network OAM&amp;P entity  110 A. In order to maintain database consistency between the active and standby instances of the network OAM&amp;P entity, active network OAM&amp;P entity  110  may regularly replicate its aggregated network SMOD and MEAL databases onto standby network OAM&amp;P entity  110 A. 
     In the event of failure or deactivation of active network OAM&amp;P entity  110 , standby network OAM&amp;P entity  110 A becomes active; local databases on network OAM&amp;P entity  110 A will from that time forward be aggregated to their corresponding databases on network OAM&amp;P entity  110 A instead of on formerly active network OAM&amp;P entity  110 , and OAM&amp;P information from each signaling network element  114  will be processed by network OAM&amp;P entity  110 A instead of by formerly active network OAM&amp;P entity  110 . 
       FIG. 3  is a block diagram of an exemplary signaling network element  114  in accordance with an embodiment of the subject matter described herein. In  FIG. 3 , signaling network element  114  includes an active instance  116  of system OAM&amp;P entity and at least one standby instance  116 A of system OAM&amp;P entity adapted to become active in response to detection of a failure or deactivation of active system OAM&amp;P entity  116 . system OAM&amp;P entity  116  may include an admin server  300  which communicates with a network operations center (not shown) via XMI  106 . 
     Admin server  300  may handle incoming requests from the GUI and provisioning interfaces and return responses to those requests. In addition, admin server  300  may autonomously display data, such as current alarm configuration, current measurements, or current logs, as configured by the user. According to one embodiment, admin server  300  may access aggregate stateful managed object data (SMOD) databases  302  via SMOD client  304 , aggregate measurements, events, alarms, and logs (MEAL) databases  306  via MEAL client  308 , and configuration and provisioning databases  310  via DB client  312 . In the example illustrated in  FIG. 3 , system SMOD databases  302  may be accessed also by network SMOD server  218  within OAM&amp;P network element  108 , for aggregation into the network SMOD databases  202 . Similarly, the system MEAL databases  306  may be accessed also by network MEAL server  226  for aggregation into the network MEAL databases  206 . Configuration and provisioning databases  310  may be accessed also by network DB server  234  within OAM&amp;P network element  108 . 
     Managed objects (MO) manager  314  is an interface through which changes to managed object states may be recorded. MO manager  314  may operate locally on system OAM&amp;P entity  116  and may write each change record to local SMOD databases  316 . Periodically, SMOD server  318  on active system OAM&amp;P entity  116  may ask local SMOD client  320  to pull all of the entries from local SMOD databases  316  for collection in aggregate system SMOD databases  302 . 
     Alarm and event manager  322  is an interface through which alarms and events may be generated. Alarm and event manager  322  may operate locally on system OAM&amp;P entity  116  and may generate SNMP traps corresponding to the alarms and events detected. Alarm and event manager  322  may send the SNMP traps via the fault monitoring interface component of XMI  106  to a northbound fault management system in network operations center  102 , if configured. Alarm and event manager  322  may be one of the local managers for MEAL data. As active system OAM&amp;P entity  116  updates alarms and events locally, alarm and event manager  322  may update the local MEAL database  324  with the requested change and may write the change to system MEAL databases  306 . Periodically, MEAL server  326  on active system OAM&amp;P entity  116  may ask local MEAL client  328  to pull the latest entries from local MEAL databases  324  for collection in aggregate system MEAL databases  306 . 
     Measurement manager  330  is an interface through which measurements may be generated; it may operate locally on system OAM&amp;P entity  116  and may write a change to local MEAL databases  324 . Periodically, MEAL server  326  on active system OAM&amp;P entity  116  may ask local MEAL client  328  to pull the latest entries from local MEAL databases  324  for collection in aggregate system MEAL databases  306 . 
     Logging manager  332  is an interface through which log entries may be generated. Logging manager  332  may operate locally on system OAM&amp;P entity  116  and may write each entry to local MEAL databases  324 . Periodically, MEAL server  326  on active system OAM&amp;P entity  116  may ask local MEAL client  328  to pull the latest entries from local MEAL databases  324  for collection in aggregate system MEAL databases  306 . 
     Configuration and provisioning databases  310  contain configuration and provisioning information and may also be accessed by DB server  334 . The responsibilities of DB server  334  may include replication of configuration and provisioning information into the standby instance of system OAM&amp;P entity  116 A and into message processing entity  118 , and communication of configuration or provisioning messages to message processing entity  118 . 
     In the example illustrated in  FIG. 3 , standby system OAM&amp;P entity  116 A is assumed to be configured as an identical copy of active system OAM&amp;P entity  116 . The role of standby system OAM&amp;P entity  116 A is to be ready to provide OAM functions and provisioning functions for the network element under its control, in the event that active system OAM&amp;P entity  116  fails or is otherwise deactivated. This means that standby system OAM&amp;P entity  116 A may keep up with all user, administration, provisioning, configuration, database management, fault management, and upgrade changes made by active system OAM&amp;P entity  116 , but standby system OAM&amp;P entity  116 A does not provide these functions. In standby system OAM&amp;P entity  116 A, configuration and provisioning databases  310 , DB client  312 , MO manager  314 , local SMOD databases  316 , alarm and event manager  322 , local MEAL databases  324 , measurement manager  330 , and logging manager  332 , may function and operate the same as do their counterparts in active system OAM&amp;P entity  116 . However, in standby system OAM&amp;P entity  116 A, SMOD and MEAL data may be aggregated into the SMOD and MEAL databases on active system OAM&amp;P entity  116  rather than on standby system OAM&amp;P entity  116 A. In order to maintain database consistency between the active and standby instances of the system OAM&amp;P entity, active system OAM&amp;P entity  116  may regularly replicate its aggregated system SMOD and MEAL databases onto standby system OAM&amp;P entity  116 A. 
     In the event of failure or deactivation of active system OAM&amp;P entity  116 , standby system OAM&amp;P entity  116 A becomes active; local databases on system OAM&amp;P entity  116 A will from that time forward be aggregated to their corresponding databases on system OAM&amp;P entity  116 A instead of on formerly active system OAM&amp;P entity  116 , and OAM&amp;P information from message processing entities  122  will be processed by system OAM&amp;P entity  116 A instead of by formerly active system OAM&amp;P entity  116 . 
       FIG. 4  is a block diagram of an exemplary message processing entity  118  operating within a hierarchical OAM&amp;P architecture in accordance with an embodiment of the subject matter described herein. The role of message processing entity  118  includes providing the application messaging protocol interfaces and processing. In addition, message processing entity  118  may also have its own OAM&amp;P components. Message processing entity  118  may be configured to replicate databases from system OAM&amp;P entity  116  and generate faults to a fault management system. MEAL and SMOD data may be sent by message processing entity  118  to system OAM&amp;P entity  116 . 
     According to one embodiment, managed objects (MO) manager  400  is an interface through which changes to managed object states may be recorded. MO manager  400  may operate locally on message processing entity  118  and may write each change record to local SMOD databases  402 . Periodically, local SMOD client  404  may be requested to pull all of the entries from local SMOD databases  402  for collection in aggregate system SMOD databases  302 . 
     Alarm and event manager  406  is an interface through which alarms and events may be generated. Alarm and event manager  406  may operate locally on message processing entity  118  and may generate SNMP traps corresponding to the alarms and events detected. Alarm and event manager  406  may send the SNMP traps via the fault monitoring component of XMI  106  to a northbound fault management system in network operations center  102 , if configured. Alarm and event manager  406  may be one of the local managers for MEAL data. As message processing entity  118  updates alarms and events locally, alarm and event manager  406  may update local MEAL databases  408  with the requested change. Periodically, MEAL server  326  on system OAM&amp;P entity  116  may ask local MEAL client  410  to pull the latest entries from local MEAL databases  408  for collection in aggregate system MEAL databases  306 . 
     Measurement manager  412  is an interface through which measurements may be generated. Measurement manager  412  may operate locally on message processing entity  118  and may write a change to local MEAL databases  408 . Periodically, MEAL server  326  on system OAM&amp;P entity  116  may ask local MEAL client  410  to pull the latest entries from the local MEAL databases  408  for collection in the aggregate system MEAL databases  306 . 
     Logging manager  414  is an interface through which log entries may be generated. Logging manager  414  may operate locally on message processing entity  118  and may write each entry to local MEAL databases  408 . Periodically, MEAL server  326  on system OAM&amp;P entity  116  may ask local MEAL client  410  to pull the latest entries from local MEAL databases  408  for collection in aggregate system MEAL databases  306 . 
     Configuration and provisioning databases  416  contain configuration and provisioning information and may also be accessed by one or more applications  120  via DB manager  418 . Message processing entity  118  may be connected to signaling network  128 , and may include one or more applications  120 —performing, for example, different IMS functions, variants of the same IMS function, or different instances of the same IMS function. Configuration data may be sent from system OAM&amp;P entity  116  to message processing entity  118  via system DB server  334  and local DB client  420 . The configuration data received by message processing entity  118  may include a command to activate, deactivate, or change the application or applications  120  performed by message processing entity  118 . 
     According to one embodiment, a standby message processing entity  118  may be configured as an identical copy of message processing entity  118  and adapted to become active in response to detection of a failure or deactivation of the active message processing entity  118 . The role of the standby message processing entity  118  is to be ready to provide message processing functions in the event that the message processing entity  118  fails or is otherwise deactivated. In the event of failure or deactivation of message processing entity  118 , the standby message processing entity  118  becomes active and assumes performance of the associated applications  120 . 
     According to another embodiment, multiple message processing entities  122  may be configured as identical copies of active message processing entity  118  operating in a manner so as to allow load-sharing between the multiple instances of message processing entity  118 . 
       FIG. 5  is a flow chart illustrating an exemplary process for providing a hierarchical OAM&amp;P system for managing an IMS system in accordance with an embodiment of the subject matter described herein. Referring to  FIG. 5 , in step  500  a network OAM&amp;P function is performed. Performing a network OAM&amp;P function may include processing and aggregating OAM&amp;P information that has been received from one or more instances of system OAM&amp;P entity  116 , and communicating the OAM&amp;P information with operator&#39;s network  104 , through which OAM&amp;P information will be communicated with a network control entity, such as network operations center  102 . In step  502 , a system OAM&amp;P function is performed. Performing a system OAM&amp;P function may include processing and aggregating OAM&amp;P information that has been received from one or more instances of message processing entity  118 , and communicating the OAM&amp;P information with network OAM&amp;P entity  110 . In step  504 , a message processing function is performed. Performing a message processing function may include processing signaling information and implementing one or more applications  120 , which generate OAM&amp;P information, communicating the OAM&amp;P information with the system OAM&amp;P entity  116 , the network OAM&amp;P entity  110 , or both, and receiving configuration or provisioning information by which the application or applications  120  may be activated, deactivated, or modified. 
       FIG. 6  is a flow chart illustrating an exemplary process for remotely configuring an IMS entity in accordance with an embodiment of the subject matter described herein. Referring to  FIG. 6 , in step  600 , the presence of a configurable IMS entity, such as a configurable message processing entity  118 , may be detected using a system OAM&amp;P entity  116 . The presence may be detected by communication of a status message, generated by the configurable IMS entity in response to activation of the configurable IMS entity, and received by system OAM&amp;P entity  116 . The status message may include a list or description of the capabilities of the configurable IMS entity. In step  602 , system OAM&amp;P entity  116  may communicate the detection to network OAM&amp;P entity  110 . In step  604 , network OAM&amp;P entity  110  may provide the operator, such as an operator at network operations center  102 , with options to configure the IMS entity based on the capabilities of the IMS entity, as reported by the IMS entity during the detection process. In step  606 , the operator may select the desired application or applications  120  to be activated, and convey that to network OAM&amp;P entity  110 . In step  608 , network OAM&amp;P entity  110  may convey the selection to system OAM&amp;P entity  116 , which may configure the IMS entity to activate the selected application or applications  126  or may convey the selection to the IMS entity so that the IMS entity may configure itself. 
     It will be understood that various details of the invention may be changed without departing from the scope of the invention. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.