CHALLENGES OF BUILDING END-TO-END NETWORK

TOPOLOGIES FOR MULTI-SERVICE NETWORKS

Anne-Marie Bosneag and David Cleary

Ericsson Ireland Research Centre, Ericsson LMI, Cornamaddy, Athlone, Ireland

Keywords:

End-to-end network topology, multi-service networks, inventory solutions, service oriented architecture.

Abstract:

Building an end-to-end view of the network in multi-service networks is a very important building block in

creating a correct view of the capabilities of the network and is therefore crucial for service deployment,

activation and management. At the same time, it is a very difﬁcult task to achieve. Current inventory solutions

are static in nature, which introduces problems of data consistency between the managed domain and the view

at the management node. An end-to-end view of the network is also hard to achieve because no common data

model is in use today, and inventory information between different domains is very hard, if not impossible, to

obtain using the current solutions.

This paper discusses the challenges of building an end-to-end view of the network topology, discusses existing

solutions, and proposes Stratus, a ﬂexible uniﬁed SOA-based architecture that has been implemented and

deployed in our lab. Stratus is based on the MTOSI recommendations for inventory retrieval, and comes with

a mechanism for data mapping from domain managers for Public Ethernet and Core Wireline Access Networks

to the MTOSI model. It also provides dynamic discovery of the different domains in the network, automatic

end-to-end topology creation, and notiﬁcation systems for automatic updates of the topology based on updates

in the network. The experiments show that the proposed solution is technically feasible and compatible with

existing inventory solutions.

1 INTRODUCTION

An accurate and timely model of the inventory of re-

sources in a mobile telecommunication network pro-

vides support for network planning, and correct and

effective operation and maintenance. Building an up-

to-date, accurate representation of the network inven-

tory in an OSS (Operation Support System) is a chal-

lenging problem in the current static inventory solu-

tions. Moreover, solutions for different types of net-

works have been developed for a long time without

relying on a common data model, and usually no in-

ventory information reﬂects resources that link differ-

ent domains, such as physical links between two do-

mains.

A common solution in today’s commercially de-

ployed systems is to rely on external inventory sys-

tems, which get the inventory data from the different

domains in the network, interpret it, and provide it

to the operator in a common format. However, such

a solution is static, being based on transferring the

entire inventory data from domains (usually through

FTP), followed by intensive processing and aggrega-

tion. The resulting inventory will therefore reﬂect the

state of the network at the time of getting the inven-

tory data from the network, and not at the time of pre-

senting it. It also does not reﬂect data about resources

between domains.

In this paper, we describe our practical experience

with implementing an inventory service that is based

on a common data model (TMF MTNM – TeleMan-

agement Forum Multi-Technology Network Manage-

ment), is able to provide an end-to-end view of the

network topology, and reacts in real time to changes

in the network.

The study outlines the different approaches to in-

ventory data modeling that have been proposed to

date, and discusses the shortcomings of existing in-

259

Bosneag A. and Cleary D. (2007).

CHALLENGES OF BUILDING END-TO-END NETWORK TOPOLOGIES FOR MULTI-SERVICE NETWORKS.

In Proceedings of the Second International Conference on Wireless Information Networks and Systems, pages 243-250

DOI: 10.5220/0002149902430250

 SciTePress

ventory systems. It then introduces Stratus, a ﬂexible

architecture for providing an end-to-end view of the

network. Stratus is based on a Service Oriented Ar-

chitecture, in which the different inventory providers

(i.e., Domain Managers) are Web Service implemen-

tations of the MTNM inventory data model. Dynamic

aspects are incorporated into the architecture: the Do-

main Managers are dynamically discovered and ac-

cessed, while changes in the network are detected and

clients get alerted through asynchronous notiﬁcation

systems. To provide an end-to-end view of the net-

work, Stratus also allows the operator to deﬁne inter-

domain links.

For the testing scenario, two Domain Managers

were used: Ericsson’s Multi-Service Networks Oper-

ations & Support System (MN-OSS), providing in-

ventory information for the core wireline access in

both next generation networks and circuit switched

networks, and Ericsson’s Public Ethernet Manager

for Multi-service Access Nodes (PEM), offering ded-

icated management for broadband access networks.

Translation of inventory data from the proprietary for-

mat used by these two domains to the MTOSI data

model is provided, along with the ability to create

inter-domain links (also added to the inventory in

MTOSI format). The dynamic features mentioned in

the previous paragraph have been implemented us-

ing the BEA products for Web Services (WebLogic

Server and AquaLogic Service Registry). The deploy-

ment proves that Stratus is compatible with existing

inventory solutions, to which it adds value by provid-

ing an accurate end-to-end topological view.

The paper is organized as follows: Section 2 de-

scribes the different approaches to data modeling that

have been in use or proposed by different standardiza-

tion bodies in telecom, while Section 3 brings forth

issues related to existing architectures for inventory

systems. Section 4 introduces the architecture used in

Stratus, and explains how this architecture addresses

the problems that exist in current inventory systems.

Section 5 presents the scenario and the deployment

used for testing the architecture proposed, and ﬁnally,

Section 6 presents conclusions and future work direc-

tions.

2 CURRENT APPROACHES FOR

INVENTORY DATA MODELING

2.1 Taxonomy of Approaches

The importance of inventory information prompted a

lot of activity in the area of inventory systems. Typi-

cally, the inventory information in a telecom network

is classiﬁed into three groups deﬁning inventory func-

tions; these are product, services and resources. Each

of these functions have their own set of entities and

relationships speciﬁc to the business logic, and inter-

actions with other OSS functions. However, all in-

ventory applications share a common set of abstrac-

tions. If we analyze the current approaches we can

see a simple taxonomy emerging. At the heart of this

taxonomy stay information representation and access.

• Deep Modeling or detailed modeling of the un-

derling network with typed ﬁnely-grained access

to the information model: This category is in-

teresting as it places most of the intelligence in

the structure of the information model. As the

model is strongly typed, access to it normally re-

sults in a speciﬁc application programming inter-

face with strong data typing. The key advantage

of this approach is that the model is explicitly in-

teroperable. However, strongly typed systems are

hard to agree on and standardize, and are nor-

mally very speciﬁc to the network infrastructure

(such as ATM/IP). Such an approach can be seen

in DMTF CIM (Tosic and Dordevic-Kajan, 1999),

TMF MTNM (TeleManagementForum, b), TMF

MTOSI (TeleManagementForum, c).

• Shallow Modeling or abstract modeling of net-

work resources with generic access mechanisms:

This category strives to remove the concept of

strong typing. The information model introduces

the concept of Managed Object as a generic con-

tainer for inventory information. This approach

stems from the seminal work on network manage-

ment put forward by ITU-T (the Telecommuni-

cation Standardization Sector of the International

Telecommunications Union) (3GPP, 2000). This

approach allows for syntactical interoperability,

but requires the semantics to be captured in the ap-

plication logic. The current third generation 3GPP

IRP (TS32.695, 2006) follows this approach.

• Meta Modeling is a mixture of the ﬁrst two mod-

els, normally modeling the underlying capability

of the various networks. In this approach a trade-

off is reached, between the difﬁculty of agree-

ing on a strongly typed model and capturing the

semantics in the application logic, by a model

layer that captures some meta-modeling making

the data easier to process. A good example is the

JSR 142 (TeleManagementForum, a).

In the next subsection, we take a look at a current

proposal regarding inventory systems for wireless net-

working.

WINSYS 2007 - International Conference on Wireless Information Networks and Systems

260

Figure 1: MTOSI model for Managed Domain.

2.2 Inventory for Wireless Networks

A very important point to be made when talking about

wireless network inventories is that the inventory is

an end-2-end concept from the operator’s perspec-

tive. The goal is to create an all encompassing view

of network resources and services. This becomes

even more important in the context of multi-service

networks, where there is a heterogeneous mixture of

access technologies that facilitate wireless edge con-

nectivity. Typically, the termination points are repre-

sented by a home/ofﬁce environment. More and more

often, this termination is no longer a termination in

the classic sense, but a gateway or bridge to a wire-

less network. If we have an objective to allow global

services to roam into these new networks, it is imper-

ative that we capture the global, end-to-end view in

our inventory data.

MTOSI (Multi-Technology Operations Systems

Interface) is the basis for a full-featured, carrier-

grade, scalable solution that provides a uniﬁed, open

interface between Operations Support Systems (OSS)

for the purpose of network and service management.

MTOSI is a single standard (TMF 854) whose goal

is to decrease the complexity and avoid un-necessary

repetition of work when integrating a multitude of

OSS systems together. In the context of the taxonomy

presented above, it is an XML binding of the MTMN

modeling standard that focuses on the areas of inven-

tory and alarms:

• Inventory retrieval: through this functionality,

systems can retrieve inventory data from OSs

• Inventory notiﬁcations: notiﬁcations of changes

in the inventory data are reported to interested par-

ties

• Alarm reporting: this functionality allows an OS

to send requests to a set of interested OSs

• Active alarm retrieval: through this functionality,

Figure 2: Current inventory in systems.

an OS is able to retrieve the set of active alarms

known to another OS.

Figure 1 shows the top level of the MTOSI model,

where the concepts such as Management Domain,

Managed Element, and Topological Link exist. We

highlight these concepts here, as they were used in

our implementation, as explained in the next sections.

3 THE END-TO-END NETWORK

TOPOLOGY ISSUE

Apart from the problem of aligning all Domain Man-

agers to provide inventory data using a uniﬁed data

model, as discussed in the previous section, an ar-

chitecture for an end-to-end topology system presents

additional challenges. We focus here on the following

problems:

1. lack of an end-to-end topological view of the net-

work

2. inconsistencies between the live state of the net-

work and the perceived state at the management

node

3. static vs. dynamic approach

4. level of aggregation of inventory data

5. compatibility with existing inventory providers

6. platform independence

Current inventory systems rely on getting infor-

mation about parts of the network and then aggregat-

ing this information to create an end-to-end view of

the network. With the capabilities offered by current

inventory systems, which are mostly FTP-based (Fig-

ure 2), creating this end-to-end view requires a lot of

processing and aggregation at high levels in the ar-

chitecture, even at the level of an external inventory

system (such as Cramer, Telcordia, MetaSolv). More-

over, inter-domain inventory data is usually not avail-

able and very hard, if not impossible, to infer.

CHALLENGES OF BUILDING END-TO-END NETWORK TOPOLOGIES FOR MULTI-SERVICE NETWORKS

261

The goal of our work is to provide an extension

to current inventory systems, that is compatible with

current inventory providers in the network, and that

is able to offer an end-to-end view of the topology.

Compatibility with existing inventory providers (or

domain managers) in the network is obviously es-

sential, as the cost of introducing the new solution

is much lower if current deployments are upgraded

than if a completely new system must be put in place.

Current inventory data will still be used, and nonex-

istent data related to resources between domains will

be added to the current view, the result being an end-

to-end view of the network topology.

Platform independence is also a requirement for a

system that spans domains. A good solution should

work equally well on different platforms. Since

Web Services provide a platform-independent way of

leveraging a speciﬁc functionality, they are a good

choice to match the goal. In Section 4 we present an

architecture based on Web Services.

Another major issue with current inventory sys-

tems is that they are usually static. This leads to data

inconsistencies, increased overhead and delay in re-

ﬂecting changes in the network, and also presents a

problem when aggregating data over several domains

if the domains themselves have changed. Since static

approaches capture the state of the network at the time

of the inventory request, and no automatic updates no-

tify the inventory system of changes taking place in

the meantime, inconsistencies between the state of the

network and the view of the inventory system are in-

troduced (Brennan et al., 2006). At the same time,

changes affecting the availability of domain man-

agers, or their properties, can have an impact on the

ﬁnal end-to-end topological view, and without auto-

matic notiﬁcations regarding the changes, an incorrect

network view will be created at the management node.

Therefore, one of the requirements for our system is

to incorporate automatic notiﬁcation services that al-

low the update of the topological view as changes in

the network take place.

4 STRATUS: A UNIFIED

ARCHITECTURE FOR AN

END-TO-END SOLUTION

In this section we describe a ﬂexible, SOA-based ar-

chitecure for inventory solutions, that addresses the

issues presented in the previous section. This archi-

tecture provides:

• a uniﬁed model for presenting inventory data to

outside systems – all inventory data is presented

Figure 3: Stratus architecture.

in an XML-based format that conforms to the

MTOSI speciﬁcation

• end-to-end topology creation – in addition to pre-

senting all inventory data from individual do-

mains, an end-to-end view of the network is cre-

ated by facilitating creation/ destruction of inter-

domain links. The new links are presented accord-

ing to the same MTOSI speciﬁcation.

• automatic discovery of network domains and of

management nodes – the network domains are

discovered through the UDDI, and clients can

therefore dynamically bind to them to retrieve in-

ventory data for that particular domain. More-

over, all changes regarding additions/ deletions/

changes in properties of the domains are automat-

ically sent to clients from the UDDI.

• automatic updates of inventory data within the do-

mains – asynchronous notiﬁcations are sent via a

JMS queue from each of the domain managers to

the Link Manager, whenever changes in the inven-

tory data within the domain took place.

The architecture is presented in Figure 3. Two

domain managers DM

and DM

are represented in

the ﬁgure: these managers are providers of inventory

data for the two domains, for example IP and ADSL

as in the ﬁgure. The two domain managers are Web

Services, registered with the UDDI ((1) in Figure 3).

They offer inventory information for the domain in a

common data model (the MTOSI format).

The Link Manager is the module responsible for

the creation of the end-to-end network topology view.

This module will discover the available network do-

mains by querying the UDDI for available Domain

Managers. Once these are discovered, each domain

can be accessed and inventory data retrieved (2). To

create the end-to-end view, the Link Manager needs

WINSYS 2007 - International Conference on Wireless Information Networks and Systems

262

information about links between the domains, in ad-

dition to the inventory data from each domain. This

information can be created/ modiﬁed/ deleted through

a functionality offered by the Link Manager, and fur-

ther presented to external systems, such as Cramer,

using the same data model (MTOSI) (3).

The UDDI also sends automatic notiﬁcations to

the Link Manager when changes pertaining to the

registered Domain Managers are detected (4). The

changes detected are: new Domain Manager reg-

istered with the UDDI, existing Domain Manager

deleted from the UDDI, type of Domain Manager

changed in the UDDI. The ﬁrst two types of changes

refer to changes in the number and/or the identity of

the Domain Managers, while the last type of change

is very useful in upgrade situations, when for example

a newer version of the Domain Manager is available

for providing inventory information.

The architecture also includes a JMS queue, used

for notiﬁcations of inventory data changes. Each Do-

main Manager is responsible for monitoring its own

domain and whenever changes are taking place, a

message is sent to the JMS queue, from where they

are asynchronously delivered to the Link Manager

(5).

The next paragraphs expand on the architectural

concepts outlined at the beginning of this section, by

presenting how the architectural choices enable the

implementation of these concepts, and also how these

concepts address the problems outlined in Section 3.

The uniﬁed data model follows the MTOSI inven-

tory data model. The focus is on information associ-

ated with physical links, respectively on the resource

model associated with Equipment, Physical Termina-

tion Point and Topological Link, as presented in Sec-

tion 2.

Compatibility with existing inventory providers is

ensured by the fact that the current Domain Managers

are based on the existing inventory providers, which

are extended to include a translator from the inter-

nal, domain-speciﬁc inventory format to the MTOSI

format, and a Web Service interface. We are cur-

rently using domain-speciﬁc translators for the con-

version, and plan to go towards more automatic meth-

ods in the future. Each Domain Manager becomes a

Web Service that registers with a central UDDI, to

enable dynamic discovery and binding. The choice

of the Web Service technology also ensures platform

independence. All messages sent through the system

between the different elements (Figure 3) are SOAP

messages, and the messages carrying inventory or no-

tiﬁcation information also conform with the MTOSI

model.

Figure 4: End-to-end topological view enabled by creation

of links between domains.

An end-to-end topological view is created at the

level of the Link Manager. This is achieved by al-

lowing users to input information about physical links

between managed domains, as well as to modify and

delete this type of information. Figure 4 presents the

method for creating a new inter-domain link. The start

and end points for the topological link are provided

by the user in the form <Managed Domain, Managed

Element, Physical Termination Point>. Once these

entries are validated against the inventory data pro-

vided by the relevant Domain Managers, a new ob-

ject of type TopologicalLink is created, and added

to the inventory data. MTOSI-compliant messages

getAllTopologicalLinks/ getAllTopologicalLinksRe-

sponse are used for retrieving information about ex-

isting topological links.

By providing this functionality, Stratus covers a

gap that exists in current inventory systems, in which

information about links between domains is not stored

anywhere. The architecture also allows aggregation

of inventory data closer to the managed domains, as

opposed to aggregation at the level of third party sys-

tems, such as an external inventory system.

Dynamic discovery of the managed domains is

achieved through the UDDI. The UDDI performs two

functions in the context of the Stratus architecture:

• discovery of existing Domain Managers – at the

time of creation/ activation, each Domain Man-

ager registers with the UDDI as provider of in-

ventory data for a particular type of domain. This

registration is done manually in Stratus, an auto-

mated method being forseen for future work.

The Domain Managers register in the UDDI as in-

ventory providers, following a taxonomy that in-

cludes type (e.g., Domain Manager for the Pub-

lic Ethernet Access Network) and version (e.g., v

2.3.). Therefore, when a Domain Manager regis-

ters with the UDDI, it will also be classiﬁed ac-

cording to this taxonomy. Discovery of domains

is performed by querying the UDDI for registered

services of type inventory provider (with certain

CHALLENGES OF BUILDING END-TO-END NETWORK TOPOLOGIES FOR MULTI-SERVICE NETWORKS

263

Figure 5: Asynchronous notiﬁcation system for changes in

the inventory data.

characteristics, according to the described taxon-

omy).

• notiﬁcations of changes with the registered Do-

main Managers – whenever changes are regis-

tered with the UDDI, such as new Domain Man-

ager registers, or existing Domain Manager is

deleted, or the characteristics for an existing Do-

main Manager change (e.g., it is upgraded to

a higher version), the UDDI sends notiﬁcations

to the client Link Manager (who registered for

receiving notiﬁcations for events related to ser-

vices of type inventory provider). For the im-

plementation, we used the BEA AquaLogic Ser-

vice Registry 2.1, which is fully compliant with

UDDI v 3, which provides support for user-

deﬁned taxonomies and notiﬁcation services re-

garding changes in the registered Web Services.

Such a dynamic and ﬂexible architecture is com-

pliant with the MTOSI recommendations, and brings

advantages over the currently used static architectures

in terms of effort and response time to changes in the

system.

Another dynamic feature offered by the proposed

architecture is an asynchronous notiﬁcation system

that detects and notiﬁes clients of changes in the in-

ventory data within domains. Figure 5 presents the

implementation of this notiﬁcation system. Each Do-

main Manager monitors its own domain and when-

ever changes in the inventory data are detected, a

MTOSINotify message is sent to the JMS queue in

the system, under the topic InventoryDataChanged.

Clients such as the Link Manager register a message

listener with the JMS queue, for notiﬁcations on the

same topic. Whenever a message arrives at the des-

tination, the JMS provider delivers the message by

calling the listener’s onMessage method, which acts

on the contents of the message (it queues updates in

Link Manager and makes them available for display-

ing).

This notiﬁcation system addresses data inconsis-

tency issues that exist in current systems between the

Figure 6: Deployment of Stratus prototype.

live state of the network and the perceived state at the

management node, in that it ensures that the most cur-

rent data is always seen by the management node.

5 EVALUATION OF THE

APPROACH

The Stratus prototype was implemented and deployed

in our lab, as depicted in Figure 6. Real data from two

Domain Managers (Ericsson’s Multi-Service Net-

works Operations & Support System – MN-OSS, and

Ericsson’s Public Ethernet Manager for Multi-service

Access Nodes – PEM) was used for testing purposes.

The MN-OSS product manages the core wireline ac-

cess in both next generation networks and circuit

switched networks, while PEM offers dedicated man-

agement for broadband access networks. Both of

them offer information about physical links between

the nodes in the managed domain, in their own propri-

etary format. To fully prove backward compatibility

with existing Domain Managers, the prototype was

implemented on the Solaris platform normally used

to run MN-OSS and PEM.

For the development of Web Services, UDDI, and

JMS queue, we used the BEA products. The We-

bLogic Server WLS 8.1 (highest fully developed ver-

sion at the time of prototype implementation) was

used for developing the Web Services, while for

the UDDI we used the AquaLogic Service Registry

ALSR 2.1, which is fully compliant with UDDI v3.

For the JMS queue, we used the one included in the

distribution of WLS 8.1.

The scenario considered is depicted in Figure 7.

The network includes Core Wireline and Public Eth-

ernet domains, managed respectively by MN-OSS

and PEM, as well as wireless networks such as 3G,

managed by OSS-RC. The inventory system gathers

information from all these Domain Managers, and

WINSYS 2007 - International Conference on Wireless Information Networks and Systems

264

Figure 7: Deployment scenario.

feeds relevant data (the end-to-end view, capabilities,

etc.) into BSS (Business Support System).

The cases studied in our tests are:

1. discovery of and dynamic binding to existing do-

main managers – the Link Manager enquires the

UDDI for a list of available Domain Managers

that offer inventory data. Once these are returned,

they can be accessed directly by the Link Man-

ager. The inventory information from each of the

domains is displayed in MTOSI-compliant format

(Figure 8).

2. creation/deletion of inter-domain physical links

– the input data (<Domain, Network Element,

Port> for start and end points in the case of cre-

ation, and linkUserLabel in the case of deletion)

is veriﬁed against the existing inventory data. If

the information is correct, the link is created and

displayed in MTOSI format, respectively deleted

from the end-to-end inventory.

3. changes in inventory data within a domain – both

the MN-OSS and the PEM managers monitored

their own inventory ﬁle. Whenever a change was

detected, a notiﬁcation was sent to the Link Man-

ager through the JMS Queue. The BEA visual-

ization tool enabled tracking of these messages

to prove correctness and timeliness of the mecha-

nism.

4. new domain added / existing domain deleted /

type of domain changed – all these changes were

simulated by registering, un-registering, or chang-

ing the version for the PEM domain. All changes

were correctly propagated to the Link Manager

and further displayed onto the screen.

The tests prove the compatibility with existing

Domain Managers (MN-OSS, PEM), the correctness

of our solution, and the technical feasibility of the im-

plementation on the existing platform.

Figure 8: Available Domain Managers and Inventory Data

presented according to the MTOSI model.

6 CONCLUSIONS AND FUTURE

WORK

The main contributions of this paper are presenting

an overview of current inventory solutions, with the

different approaches and problems of existing inven-

tory systems, as well as presenting our practical im-

plementation of a ﬂexible inventory system that pro-

vides an accurate end-to-end topological view of the

network following the MTOSI standard format. The

system monitors changes in the network and reacts

in a timely fashion. Our study shows the feasibility of

the approach and compatibility with current inventory

solutions.

For future work, we plan to extend the use of SOA

to include sematic data representation, to facilitate au-

tomatic methods for mapping the domain-speciﬁc in-

ventory data to the standard MTOSI model, as well

as to use semantic Web Services for discovery of Do-

main Managers as opposed to the central UDDI based

discovery.

ACKNOWLEDGEMENTS

The authors would like to thank to their Ericsson

colleagues for their comments and contributions, in-

cluding Tony Thisted Jakobsen, Jan Groenendijk,

Alan Babington, James Sweeney, Epifanio Salamanca

Cuadrado, Javier Baliosian, Boris Danev, and Fran-

coise Sailhan. We would also like to thank to BEA for

their support throughout the duration of the project.

The research of Anne-Marie Bosneag is funded by the

European Community’s Marie Curie Fellowships for

the Transfer of Knowledge action.

CHALLENGES OF BUILDING END-TO-END NETWORK TOPOLOGIES FOR MULTI-SERVICE NETWORKS

265

REFERENCES

3GPP (2000). 3GPP TS 23.002 3rd Generation Part-

nership Project; Technical Speciﬁcation Group Ser-

vices and Systems Aspects; Network Architecture. In

http://www.itu.int/rec/T-REC-M.3010/en. ITU-T.

Brennan, R., O’Gorman, G., Doherty, C., Hurley, N., and

Olsson, S. (2006). Autonomic Replication of Man-

agement Data. In In Proc. of the IEEE/IFIP Network

Operations And Management Symposium (NOMS 06).

TeleManagementForum. OSS/J, JSR 142: OSS Inventory

API, Release 2.0. TMF.

TeleManagementForum. TMF608 Version 3.3 In-

formation Agreement for MTOSI Release 1.1.

In http://www.tmforum.org/browse.aspx?catID=4133

&linkID=32482. TMF.

TeleManagementForum. TMF854 Systems Interface:

XML Solution Set for MTOSI Release 1.1. In

http://www.tmforum.org/browse.aspx?catID=4133

&linkID=32480. TMF.

Tosic, V. and Dordevic-Kajan, S. (1999). The common in-

formation model (CIM) standard - an analysis of fea-

tures and open issues. In Proc. of the 4th International

Conference on Telecommunications in Modern Satel-

lite, Cable and Broadcasting Services, page 677.

TS32.695 (2006). 3rd Generation Partnership Project;

Technical Speciﬁcation Group Services and System

Aspects; Telecommunication management; Inventory

Management (IM) Network Resource Model (NRM)

Integration Reference Point (IRP): Bulk CM eXten-

sible Markup Language (XML) ﬁle format deﬁnition

(Release 6). In http://www.3gpp.org/ftp/Specs/html-

info/32695.htm. 3GPP.

WINSYS 2007 - International Conference on Wireless Information Networks and Systems

266