In this paper, we present the management of mobile switching center (MSC) trunks and trunk groups in cellular and personal communications systems (PCS) networks. We discuss platform-centered network management approaches based on simple network management protocol (SNMP) and common management information protocol (CMIP). We also describe the Common Object Request Broker Architecture (CORBA[sup *]) solution for distributed computing and implementation of distributed objects based on Object Management Group (OMG) Interface Definition Language. CORBA appears to provide a better backbone for manager and agent applications than CMIP. In higher-level designs, the manager and agent applications can be adapted to a CMIP-style interface.

Introduction

Wireless networks, in common with other telecommunications networks, require large numbers of translations and other parameters to define their physical and logical configurations. For wireless systems, data changes are frequent because of system growth, changes in the patterns of subscriber density, and "quasi-dynamic" frequency-channel assignments, trunk assignments, and ongoing fine tuning of the system to improve the quality of service.

The management of configuration data without proper software tools is cumbersome and risky. Configuration management of a wireless system must be quick and reliable to achieve efficient, cost-effective network management (NM) with a high quality of service. In the past, each new network element (NE) of a wireless system had a corresponding operation support system to provide management capabilities. Each of these management systems had a different user interface, employed a different computing platform, and typically managed one type of NE. The total solution was the sum of all these independent, resource-consuming partial solutions. They made the NM tasks inefficient, complex, time consuming, and expensive for NEs manufactured by several vendors.

Different management systems for each NE can no longer be afforded. Therefore, the standards groups in the Alliance for Telecommunications Industry Solutions (ATIS) committee T1M1, the International Telecommunication Union (ITU), the European Telecommunications Standards Institute (ETSI), the Telecommunications Industry Association (TIA) committee TR-45, and the TeleManagement Forum (TM Forum) have defined interfaces and protocols for management systems under the umbrella of telecommunications management network (TMN).(n1)

In this paper, we discuss the management of mobile switching center (MSC) trunks, which is part of the configuration management functionality for a cellular/personal communications systems (PCS) network. In the first section, we present traditional approaches used for NM. Next, we focus on platform-centered NM approaches and discuss the use and limitations of two widely used NM schemes. Later we list the necessary requirements for configuration management of a cellular/PCS network and then devote a section to the details of trunk management. We discuss object-oriented management, modeling, and implementation techniques in a distributed system environment. Examples are presented in the graphical Unified Modeling Language.(*, n2) and in Interface Definition Language.(*, n3)

Traditional Approaches to Network Management

Traditional NM practices include a wide array of procedures, processes, and tools for configuration, fault, performance, security, accounting, and other management functions. The management functions rely on a "master-slave" relationship between operations systems and NEs. Typically, NEs have only basic operations functionality with little or no ability to control activities or make decisions beyond call processing and information transmission tasks. The operations systems perform the majority of the operations, administration, maintenance, and provisioning (OAM&P) tasks, including processing raw data generated by individual NEs to perform specific actions.

The master-slave relationship contributes to operating inefficiencies in several ways. There is little sharing of logical resources (such as data) because NEs and operations systems are designed independently. In addition, each vendor's equipment has a unique configuration and has fault-management interfaces with specific performance requirements. NM systems characterize each NE and each vendor's interface on an individual basis. This adds considerable time and complexity in introducing new services or technologies. Other factors have compounded this complexity. NM systems are often designed to optimize the task of an individual service provider's organization or work group at a particular point in time for a particular technology. This type of development is often undertaken independently by individual organizations without paying much attention to system-level interworking. Multiple copies of data-each tied to specific systems or job functions and to specific equipment vintages or implementations--are used throughout the network, creating a major data synchronization problem. Thus, it becomes difficult for a service provider to evolve services, network technologies, and NM processes in a cost-effective, timely, and competitive fashion in response to the rapidly changing environment of wireless communications systems.

Platform-Centered Management

With a platform-centered management model for a heterogeneous network, management applications are centralized in platforms, separated from the managed data and the control functions included in NEs. Platform-centered management systems require:

• Standards to unify management-agent information access across multivendor NEs. This includes standardization of managed information database structures at the agent as well as standardization of access management protocol.

• Standards to unify the meaning of managed information across multivendor systems.

• Standards to unify platform-processing environments across multivendor platforms.

Simple network management protocol (SNMP)(n4) and open systems interconnection (OSI) common management information protocol (CMIP)(n5) address the first category of standards, while complementary efforts are being pursued by organizations such as the TM Forum to address the last two categories of standards. In this section, we concentrate on the first category of standards, which govern managed information organization and access protocols.

Simple Network Management Protocol

SNMP has been designed to be an easily implemented, basic management tool that can be used to meet short-term NM needs for computer networks. SNMP standards provide a framework for defining management information protocol for the exchange of information between managers and agents. A manager is a software module that has the responsibility for managing part or all of the configuration on behalf of NM applications and users. An agent is a software module in a managed NE; it is responsible for maintaining local management information and for delivering that information to a manager by polling, or by the agent using a trap.

The SNMP agent is uniquely identified by an Internet protocol (IP) address and a user data protocol (UDP) port number. Thus, only a single agent is accessible at a given IP address. This agent can maintain only a single management information base (MIB). Therefore, within a single IP address, only a single MIB instance may exist. This unique binding of an MIB to an IP address can limit the complexity of data that an agent can offer. When a system requires multiple MIBs to manage its different components, then in order to access via a single agent these MIBs need to be unified under a single MIB tree. Situations may arise where such unification cannot be achieved. In such cases, each MIB may require its own SNMP/UDP/IP stack, leading to greater complexity in the organization of management information. In addition, the SNMP is not a standardized protocol of the ITU, the TIA, or the ETSI.

OSI Systems Management

The overall framework for OSI management is aimed at satisfying NM requirements in five functional areas specified by TMN(n6)--fault management, accounting management, configuration management, performance management, and security management. These are referred to as system management functional areas (SMFAs). OSI includes a number of general-purpose system management functions to support the SMFAs. Each functional area can be implemented as an application that relies on some subset of the system management functions. An example of an SMFA is event management service, which enables event forwarding and filtering. Event management service is part of the fault management SMFA.

These functions depend on CMIP for basic exchange of management information, which is defined using Guidelines for the Definition of Managed Objects (GDMO)(n7) and Abstract Syntax Notation 1 Language (ASN.1).(n8) CMIP provides a comprehensive set of features such as scooping, filtering, and multiple-link replies to facilitate the exchange of management information between the manager and the agent. These features offer a distinct advantage to an OSI manager by enabling it to retrieve bulk information and to retrieve selected information of interest from the agent.

OSI management uses an extended object-oriented model of managed information. Data of interest--such as noise, error, and queue length--are different forms of a time series. A generic managed-object class (MOC) is defined to describe general data attributes of the time series and to describe operations to compute functions of the time series. The MOC provides generic event notification, which can indicate changes in management variables due to error conditions being encountered. A management platform creates instances of MOCs within device agents' databases called managed object instances (MOIs). The device agent monitors the management variables in the MOL The platform, furthermore, enrolls with the agent to receive notification of error rates and excessive processor queuing. OSI management organizes MOIs in a management information tree (MIT) that is updated to reflect changes in the resources being managed. Manager-issued CMIP commands act upon object instances present in the MIT.

The OSI information model enables the definition of a complex and flexible managed object set. Distinguishing features of OSI management are inheritance, the ability to create and delete objects (thereby leading to a dynamic MIT), and the flexibility to define specific procedures that can be invoked by the manager by issuing an "action request to the managed object" (M-Action).

Configuration Management

Configuration management is responsible for putting a network in place so it can deliver service to subscribers. Configuration management interfaces with several other NM functions. Fault management accesses configuration information and may change the configuration as part of fault recovery. Performance management impacts the planning aspects of configuration and may be used to tune a configuration for performance optimization. Accounting management is tied to service provisioning as part of the billing process for service offering. Security and access-control functions are intimately integrated with the control of access to configuration functions at the manager and the agent. We concentrate on only those aspects that directly relate to configuration management as opposed to its interfaces with other NM functions.

Cellular/PCS configuration is focused on the management of resources and services in a wireless network. Resources include radio channels, data links, base stations, the MSC, the home location register, the visitor location register, and traffic and signaling links, among others. Service configuration supports the network and the subscriber data required to customize services for a specific user.

In a cellular/PCS network, a radio system's configuration is managed at both the network level and the NE level. The network level specifies the radio system's network configuration, including the creation of managed objects to represent NEs, links between NEs, and logical network functions. The network level specifies the relationships among the NEs, the links, and the logical functions as well as the physical and logical communications paths between them. A network redundancy configuration, capacity-on-demand rules, and service-degradation rules are also specified.

The NE level deals with the operational parameters and the software component modules of each managed object that is part of the network. This type of configuration management controls the operational behaviors and characteristics of the managed objects. The NE level also maintains the current operational states of the managed objects. The operational configuration of a radio network can be defined as the combination of the network and NE configurations and the current operational states of the NEs.

Trunk Management

Trunk management in a cellular/PCS network is a critical issue that involves management of trunk groups. The management of trunk groups deals with addition, deletion, renumbering, and testing of trunk groups, as well as putting trunk groups into service and removing them from service. In this section, we address these aspects of trunk management. We also discuss object-oriented management in a distributed system using CMIP and object modeling using the Unified Modeling Language with Common Object Request Broker Architecture technology.

Trunk and Trunk Group Types

A trunk is a physical resource for carrying a single channel of communication (voice, data, or control information) between an MSC and "far end" equipment. In the cellular/PCS network, the MSC supports three main types of trunks: mobile (cell site) trunks, land (public switched telephone network [PSTN]) trunks, and transit (inter-vendor) trunks.

A mobile trunk provides a single channel of communication between an MSC and a cell site. The far-end termination point for a mobile trunk is a cell site. A land trunk provides a single channel of communication between an MSC and the PSTN. The far-end termination point for a land trunk is a switch in the land network. A transit trunk provides a single channel of communication between an MSC and another MSC in the wireless network. The far-end termination point for a transit trunk is another MSC in the network.

Trunks on an MSC are numbered based on the physical connection points of the trunk circuits at the distribution frame and at the digital trunk interface (DTI) processor. The physical span connection at the DTI determines what trunk number each channel on the span will use.

On an MSC, a trunk group is a logical device that consists of a group of physical devices (trunk circuits) with identical characteristics. The three main types of trunk groups on an MSC are mobile trunk group (a group of mobile trunks), land trunk group (a group of land trunks), and transit trunk group (a group of transit trunks).

Several trunks groups can be represented on the same physical span, or one trunk group can represent several spans. The requirement is only that all physical trunk circuits within the same logical group must have all of the characteristics defined in that group's database.

Trunk Management Views

Trunk management in a cellular/PCS network can be handled using an MSC-centered view, a trunk group call processing view, a trunk group maintenance view, or trunk group functional tasks. In this section, we discuss each of these briefly.

MSC-centered view. We may consider an MSC as a center of data links and trunks. The MSC-centered view enables the user to deal with an appropriate functional partition of links and trunks into types such as mobile, land, transit, Signaling System 7 (SS7), and inter-vendor IS-41 trunks. In addition, the MSC-centered view enhances the user's understanding of the trunk group structure and assists in solving problems associated with trunk management more tractably.

Figure 1 depicts the trunks and signaling links on an MSC. Inter-MSC or transit trunks would be captured in the "Another MSC" connection. The user should be able to click on the MSC-to-"Another MSC" trunk line to get a view of all the MSCs connected to the selected MSC via transit trunk groups. From there, the user should be able to choose which MSC transit group(s) should be deleted, modified, or viewed.

The user may then choose the trunk groups associated with the selected MSC, say MSC[sub i]. The user should be provided with a tabular view of the trunk groups connecting the selected MSC to the other MSCs (Figure 2).

There are several special considerations with transit trunk groups. For each switch equipped with a transit trunk group there are generally two transit trunk groups maintained by the transit trunk routing table--a first choice and a second choice transit trunk group. Each transit trunk associated with an MSC is associated with one, and only one, of these transit trunk groups. For each transit trunk group, the remote MSC identification (ID) and the glare-continue parameter should be specified.

A similar user interaction applies for the PSTN and SS7 trunks (SS7 trunks are used only in land trunk capacities and for integrated services digital network user-part [ISUP] line support). The PSTN connection (via either normal trunks or SS7 trunks) should be partitioned among various service providers as shown in Figure 3. The user can select a particular service provider and can view trunk groups and trunks belonging to that service provider. This implies that a trunk group is owned by one and only one service provider; under no circumstances are the trunks in a given trunk group shared by multiple service providers. All trunks in a trunk group are of the same type--that is, they may be standard trunks, inter-MSC trunks, co-exchange trunks, or SS7 trunks. Thus, a trunk group should not have trunks of more than one trunk type.

Trunk group call-processing view. The trunk group call-processing view should be a tabular window that should operate in the display, change, and delete modes and should allow the user to view or set trunk call-processing parameters. This view is selected to be tabular, since it should accommodate a uniform presentation style irrespective of the number of trunks groups selected. Each row in this window should contain a trunk group's call-processing parameters such as trunk group number, trunk group signaling-direction type (incoming, outgoing, or two-way), echo cancellation status, and the trunk circuit's cell-member number.

Trunk group maintenance view. The trunk group maintenance view should also be a tabular window to accommodate uniform presentation style irrespective of the number of groups selected. Each row in the maintenance window should provide information regarding the equipped status (busy or idle), the alarm status (critical, major, or minor), fault threshold values, and incoming and outgoing threshold values. This window should operate in display/change/delete mode to allow the user to view or set maintenance-related trunk group parameters.

Trunk group functional tasks. Configuration management of trunk groups involves the following tasks:

• Add trunk group(s).

• Delete trunk group(s).

• Renumber the trunk group(s).

• Take trunk group(s) out of service.

• Put trunk group(s) into service.

• Test the trunk(s) in the trunk group(s).

Object-Oriented Management in Distributed Systems Using CMIP

An ITU-recommended management information model(n9) forms the basis to reflect on the configuration and state of modeled resources (trunks and trunk groups) upon which operations are performed when these resources are managed by a CMIP manager and an agent based on the OSI management paradigm. In this case, trunks and trunk groups are modeled in terms of managed objects in order to define a specific set of attributes, operations, and behaviors of the resources that are being modeled. The operations of the managed objects, such as "add trunk group," are performed using common management information service element (CMISE)(n10) primitives like M-Action and "replace request to the managed object" (M-Set). In this section, we define the structure of the object model that is proposed to manage trunks and trunk groups.

Trunks and trunk groups are modeled by trunk and trunkGroup managed objects. These are derived from the circuit object defined in the TM Forum Library Volume 4: OMNIPoint 1 Definitions.(n11) The circuit managed object class consists of administrativeState and operationalState attributes that indicate the state of the resource. The managed object also defines the alarmStatus attribute, which reflects the severity of any alarm pending against the resource. The a-TPInstance and z-TPInstance attributes indicate the two termination points of the trunk and the trunkGroup. The CircuitID attribute identifies the specific instance of the object and forms the name-binding attribute.

MOIs are arranged in an MIT that is developed based on the information model. For each managed class, the model specifies the superior object class under which the managed class can be created. The specific superior object instance is specified at creation time, either by the manager or by the agent itself. The tree structure is generally used to specify the physical or logical organization of the relevant resources (Figure 4). It is also called the containment tree. For example, a managed object representing a central processing unit (CPU) is instantiated under a managed object modeling a computer. A software-managed object can be instantiated under a CPU-managed object. In the case of trunk management, trunk objects are instantiated under the specific instance of the trunkGroup to which they belong. The trunkGroup objects are instantiated under the trunk subsystem managed object, which is essentially a placeholder object (it does not represent any resource).

In addition to attributes and behaviors inherited from the circuit object, new attributes, behaviors, and operations for the trunk and trunkGroup object classes are defined. These essentially specialize the object definition so as to model the specifics of trunk and trunkGroup objects. New attributes added to the class definitions include the type of trunk or trunk group, the number of trunks in a trunk group, the test status of the object, and, most importantly, the trunk or trunkGroup number, which uniquely identifies the object instance with the naming attribute value.

To enable the manager to run various tests on a trunk or a trunkGroup, an action is defined. This action is defined in the GDMO in the form of a package template so that it can be included in the definition of both trunk and trunkGroup managed object class definitions. This action specifies that, when the manager invokes an M-Action CMISE primitive on the trunk or the trunkGroup managed-object instance, a specific test is scheduled to run, either immediately or at a specified time. ITU recommendation X.745 on the OSI Systems Management: Test Management Function(n12) defines synchronous and asynchronous tests. We consider only the asynchronous tests as they are applicable to our scenario. According to the ITU recommendation, each object under test (a trunk or a trunkGroup object) is referred to as a "managed object referring to test," or MORT. An object is said to be a "test action request receiver," or TARR, if it can process M-Action requests to execute tests (Figure 5).

When the MORT receives a request for test execution, it creates a test object (TO) that represents the test request; therefore, there will be one TO for each test request. This TO has attributes that represent the properties of the test it represents. The manager can also issue an M-Action on the TO and thereby cancel the test abruptly. In the case of a trunk-management specific trunk, TO objects are defined that inherit from the TO as defined in recommendation X.745. Once the test starts executing, results are stored in the form of test-record objects for retrieval by the manager. The event-forward discriminator (EFD) will filter the test results for user notifications.

Object Modeling with UML

In the last section, we describe traditional TMN object modeling with GDMO and manager-agent interfaces with CMIP. The GDMO are designed and best used to denote containment relationships. NM and its implementation require more details than the containment relationships among managed objects. The GDMO are verbal and do not deal well with dynamic interaction between class instances. The data types as referenced in the GDMO are tagged with ASN.1 notation. The ASN.1 notation may be good for a computer to decode the scope of the containment relationships, but it is difficult for a network craft person to decode and read.

The Unified Modeling Language (UML)(n2) provides easy-to-understand graphical presentation of network entities. It gives relationships, states, and modes of interactions of network entities using UML use-cases, object class diagrams, state diagrams, sequence diagrams, collaboration diagrams, activity diagrams, and deployment diagrams. A UML use-case defines a set of action sequences that a system performs and the testable results for a particular actor (a craft person, a manager, or an agent application). UML class diagrams describe static views of a system in terms of object classes and the relationships among classes. UML state diagrams capture the life cycles of objects, subsystems, and systems. UML sequence diagrams illustrate how object instances interact with each other using messages in regards to a time line. UML collaboration diagrams focus on the interactions and the instances of association between a set of collaborating objects in a space dimension. Both the sequence diagrams and the activity diagrams capture actions and results. Actions and results are actual implementations of operations (for example, the activities and state transitions in a use-case instance of an object). Activity diagrams show concurrency, synchronization, and signaling among objects in their own swim lanes. UML component and deployment diagrams describe the physical architecture of a system. These include how classes are implemented in different code packages and how the resulting executable components are deployed in the platform in which they are executed. Table I shows UML notations for object relationships.

UML is better suited than CMIP to model a real-time system. A real-time system is characterized by the logical separation of processes and threads, objects, determinations of active object classes in real-time scenarios, communication and synchronization of active class instances, and the mapping of real-time aspects to the object implementation environment. The GDMO and CMIP provide no implementation details regarding how to implement the manager and its agent. This may result in different NM system vendors providing their own interpretation and implementation of a CMIP interface. NM systems are not open systems that allow interoperability among vendors.

We provide a UML class diagram of an MSC in Figure 6. The UML class diagram gives more details than the corresponding hierarchical MIT (Figure 4). The object-modeling tools support UML 1.0[sup 2] and generate code stubs based on the UML. Since UML 1.0 is accepted by the Object Management Group (OMG),(n13) most UML tools generate OMG Interface Definition Language (IDL). OMG IDL is used to implement Common Object Request Broker Architecture (CORBA(*)) for distributed object systems.(n13, n14)

Object Implementation and Management with CORBA

CORBA technology(n3) provides a well-defined interoperable open system architecture for Distributed Object Computing. The heart of CORBA is the Object Request Broker (ORB), which establishes client-server or manager-agent relationships among objects. The ORB is responsible for interpreting a manager's request and for finding an agent to fulfill the request and return results. The manager is not required to know the whereabouts of its agents, or to know what kind of platform(s), operating system(s), and programming language(s) the agents use to implement the requests. All local and distributed connection and error-handling details are hidden from the managers and agents by the ORB. The object modeling and manager-agent interfaces are defined using IDL in CORBA. IDL is used to write a detailed contract between the managers and their agents. A sample IDL code to perform alarm notification is shown in Table II and Figure 7. The OMG provides standard mapping of IDL to various object-oriented programming languages, such as C++, Java,(*) Ada,(n15) and Smalltalk.(n16) Because IDL is designed for various domains and applications, it is more powerful in expressing object models and interfaces than the GDMO and CMIP. In CORBA, a manager may dynamically explore the details of its managed objects at runtime using CORBA metadata. The metadata describe every client interface known to the ORB. The ORB may also be equipped with some TMN domain-specific services.(n13) The topology and notification services, for example, are targeted toward the TMN domain.

CORBA assures inter-operability among ORBs with Internet Inter-ORB Protocol (IIOP(*)).(n17) The TMN Q3 protocol stack is open to various interpretations in reference to the logical OSI stack layers. CORBA has a better specification of the IIOP among various ORBs. TMN Q3 managers and agents typically support only a single association. CORBA allows multiple TMN managers to connect to a single TMN agent and multiple TMN agents to connect to the same manager. The use of IIOP among ORBs offers fault tolerance and load balancing.

A UML class diagram graphically describes managed devices. The IDL that is required to implement objects is generated from the GDMO using a GDMO-to-IDL compiler.(n18) Mapping of the GDMO and IDL has been stable for a long time and will soon become a standard.(n19, n20) IDL is generated for ASN.1 data types, for synchronous-action and attribute interfaces, and for GDMO notifications. Once IDL is compiled into one programming language (like C++), a CORBA-compliant client stub and server skeleton will be avail able for the coding of manager and agent applications, respectively.(n3)

Conclusions

In this paper, we discussed trunk management in a cellular/PCS network using a platform-centered management approach based on the OSI management information protocol, CMIP. We presented a containment tree based on the information model to manage trunks and trunk groups. We also defined necessary attributes that need to be added to the class definition to manage trunks and trunk groups. While trunk objects and object management can be traditionally defined by the GDMO and CMIP, the dynamic real-time system behavior can be further described using the UML. We suggest the CORBA solution for Distributed Object Computing and implementation of distributed objects based on IDL. CORBA appears to provide a better backbone for manager and agent applications than CMIP. In higher-level designs, manager and agent applications can be adapted to a CMIP-style interface. The actual object framework can also be built on CORBA.

(*) Trademarks

CORBA and IIOP are registered trademarks and OMG Interface Definition Language (IDL) and Unified Modeling Language are trademarks of the Object Management Group.

Java is a trademark of Sun Microsystems, Inc.

ASN.1--Abstract Syntax Notation One language

ATIS--Alliance for Telecommunications Industry Solutions

CMIP--common management information protocol

CMISE--common management information service element

CORBA(*)--Common Object Request Broker Architecture

CPU--central processing unit

DTI--digital trunk interface

EFD--event forward discriminator

EIA--Electronic Industries Alliance

ETSI--European Telecommunication Standards Institute

GDMO--Guidelines for the Definition of Managed Objects

ID--identification

IDL--OMG Interface Definition Language(*)

IIOP(*)--OMG Internet Inter-ORB Protocol

IP--Internet protocol

IS-41--TIA/EIA Interim Standard 41 for inter-vendor trunks

ISDN--integrated services digital network

ISUP--ISDN user part

ITU--International Telecommunication Union

M-Action--action request to the managed object

MIB--management information base

MIT--management information tree

MOC--managed object class

MOI--managed object instance

MORT--managed object referring to test

MSC--mobile switching center

M-Set--replace request to the managed object

NE--network element

NM--network management

OAM&P--operations, administration, maintenance, and provisioning

OMG--Object Management Group

ORB--Object Request Broker

OSI--open systems interconnection

PCS--personal communications systems

PSTN--public switched telephone network

Q3--TMN interface

SMFA--system management functional area

SNMP--simple network management protocol

SS7--Signaling System 7

T1--ATIS Committee T1--Telecommunications

T1M1--T1 Technical Subcommittee on Internetwork Operations, Administration, Maintenance, & Provisioning

TARR--test action request receiver

TIA--Telecommunications Industry Association

TM Forum--TeleManagement Forum (formerly the Network Management Forum)

TMN--telecommunications management network

TO--test object

TR-45--TIA committee TR-45 on Mobile & Personal Communications Standards

UDP--user data protocol

UML--Unified Modeling Language(*)

DIAGRAM: Table I. UML notations for object relationships.

Legend for Chart:

A - Agent (server) sending notifications
C - Manager (client) receiving notifications

A                                       B
    C

void smEvent(                          [a]
in mcnEquipmentModule::
smEventlnfoTypenotiflnfo,
in CMIPHeader);
    void pull_smEvent(
    out mcnEquipmentModule::
    smEventlnfoTypenotiflnfo,
    out PullCMIPHeader);

oneway void smFventUnconfirmed(        [b]
in mcnEquipmentModule::
smEventlnfoTypenotiflnfo,
in CMIPHeader);
    boolean try_smEvent(
    out mcnEquipmentModule::
    sm EventlnfoTypenotiflnfo,
    out PullCMIPHeader);

void equipmentAlarm (in                [a]
CMIPHeader);
    void pull_equipmentAlarm(
    out CMIPHeader);

oneway void                            [b]
equipmentAlarmUnconfirmed(
in CMIPHeader);
    boolean try_equipmentAlarm(
    out CMIPHeader);

void qualityofServiceAlarm(            [a]
in CMIPHeader);
    void pull_qualityofServiceAlarm(
    out CMIPHeader);

oneway void                            [b]
qualityofServiceAlarmUnconfirrned(
in CMIPHeader);
    boolean try_qualityofServiceAlarrn(
    out CMIPHeader);

[a] Void pull event

[b] Boolean try event

CMIP-Common management information protocol

DIAGRAM: Figure 1. MSC-centered view of trunks and signaling links.

DIAGRAM: Figure 2. Transit trunk groups between a selected MSC and other MSCs.

DIAGRAM: Figure 3. Partition of a switch PSTN connection among service providers.

DIAGRAM: Figure 4. Management information tree.

DIAGRAM: Figure 5. Test management.

DIAGRAM: Figure 6. UML class diagram of an MSC.

DIAGRAM: Figure 7. IDL class diagram for alarm notifications.

References

(n1.) International Telecommunication Union, "Principles for a Telecommunications Management Network," ITU-T Rec. M. 3010, Version 5/1996, http://www.itu.int

(n2.) Unified Modeling Language, Rational Software Corporation, http://www.rational.com

(n3.) The Object Management Group, "The Common Object Request Broker: Architecture and Specification," Rev. 2.3, June 1999, http://www.omg.org

(n4.) J. Case, M. Fedor, M. Schoffstall, and J. Davin, "A Simple Network Management Protocol," RFC 1157, IETF, May 1990, http://www.ietf.org

(n5.) International Telecommunication Union, "Information technology--Open Systems Interconnection--Common Management Information Protocol: Specification," ITU-T Rec. X.711, Version 10/1997, http://www.itu.int

(n6.) International Telecommunication Union, "TMN Management Functions," ITU-T Rec. M.3400, Version 4/1997, http://www.itu.int

(n7.) International Telecommunication Union, "Information Technology--Open Systems Interconnection--Structure of Management Information: Guidelines for the Definition of Managed Objects," ITU-T Rec. X.722, Version 1/1992, http://www.itu.int

(n8.) International Telecommunication Union, "Specification of Abstract Syntax Notation One (ASN.1)," ITU-T Rec. X.208, Version 11/1988, http://www.itu.int

(n9.) International Telecommunication Union, "Information Technology--Open Systems Interconnection--Structure of Management Information: Management Information Model," ITU-T Rec. X.720, Version 1 / 1992, http://www.itu.int

(n10.) British Standards Institution, "Information Technology--International Standardized Profiles AOMln OSI Management--Management Communications--Part I: Specifications of AC SE, Presentation and Session Protocols for the Use by ROSE and CMISE," BS ISO/IEC ISP 11183-1, 1992.

(n11.) TeleManagement Forum (formerly the Network Management Forum), Forum Library--Vol. 4: OMNIPoint 1 Definitions, 1993, http:// www.tmforum.com

(n12). International Telecommunication Union, "Information Technology--Open Systems Interconnection--Systems Management: Test Management Function," ITU-T Rec. X.745, Version 11/1993, http://www.itu.int

(n13.) OMG Telecommunication Domain Task Force, "CORBA/TMN Interworking," Request for Proposal, The Open Management Group, http://www.omg.org/homepages/telecom

(n14.) Jan Siegel, CORBA Fundamentals and Programming, John Wiley, New York, 1996.

(n15.) United States Department of Defense, Ada Joint Program Office.

(n16.) ObjectShare, Inc. (formerly ParcPlace-Digitalk, Inc.), http: //www.objectshare.com

(n17.) Mike Bradley, "IIOP: OMG's Internet Inter-ORB Protocol: A Brief Description," White Paper, Open Management Group, May 1997, http://www.opengroup.org

(n18.) "GDIDL: a GDMO/ASN.1 to IDL translator," Smile, http://www.orbycom.fr

(n19.) The Open Group, "ASN.1 Type to CORBA-IDL Translation," Inter-domain Management: Specification Translation, X/Open Document No. C802, Nov. 1999, http://www.opengroup.org

(n20.) The Open Group, "GDMO to CORBA-IDL Translation," Inter-domain Management: Specification Translation, X/Open Document No. C809, Nov. 1999, http://www.opengroup.org

(Manuscript approved November 1999)

~~~~~~~~

By Vijay K. Garg

VIJAY K. GARG is a distinguished member of technical staff in the Learning and Performance Center of Lucent Technologies' Human Resources organization in Naperville, Illinois. He has a B.S. degree in civil engineering from Banaras University in Varanasi, India, an M.S. degree in structural engineering and structural mechanics from the University of California in Berkeley, and a Ph.D. in engineering mechanics from the Illinois Institute of Technology in Chicago. While previously assigned within Lucent's Switching and Access Solutions Group, he performed system engineering dealing with call processing and operations, maintenance, administration, and provisioning (OAM&P) aspects of wireless systems. Currently, Dr. Garg is developing courses on third-generation wireless technology for the technical community within Lucent.