Towards Standardized and Automated Fault ... - Springer Link

J Netw Syst Manage (2008) 16:63–91 DOI 10.1007/s10922-007-9094-5

Towards Standardized and Automated Fault Management and Service Provisioning for NGNs Niklas Blum Æ Piotr Jacak Æ Florian Schreiner Æ Dragos Vingarzan Æ Peter Weik

Published online: 22 December 2007 Ó Springer Science+Business Media, LLC 2007

Abstract The IP Multimedia Subsystem (IMS), already widely recognized as a fundamental core component of Next Generation Networks (NGNs), enables proliferation of a huge variety of value added services. Simultaneous to the emergence of triple play services there is a strong need for establishing standardized methodologies for service fulfillment and assurance, maintaining service execution parameters at advertised levels. Traditional Operations Support Systems (OSS) are not adequate for managing NGNs. This work shows experiences gained from implementing OSS for NGNs. It describes a solution that combines extensive NGN development expertise with a new generation, of policy-based, service oriented OSS solutions in order to provide enhanced levels of automation and reliability to the NGN service delivery and session control environment. Primary focus of this approach is put on service assurance and service fulfillment mechanisms for remote monitoring, automated control and configuration of standard compliant IMS infrastructures, such as the Open Source IMS Core (OSIMS) based Open IMS Playground. This work describes state of the art NGN OSS design principles and knowledge attained by integration of standardized fault management as well as service and subscriber provisioning procedures showing how the full cycle from N. Blum P. Jacak F. Schreiner (&) D. Vingarzan P. Weik Next Generation Network Infrastructures (NGNI) Division, Fraunhofer Institute FOKUS, Kaiserin-Augusta-Allee 31, 10589 Berlin, Germany e-mail: [email protected] N. Blum e-mail: [email protected] P. Jacak e-mail: [email protected] D. Vingarzan e-mail: [email protected] P. Weik e-mail: [email protected]

123

64

J Netw Syst Manage (2008) 16:63–91

service deployment to service advertisement to service execution can be delivered in an automated way. Keywords IP Multimedia Subsystem New Generation Operations Systems and Software Service Oriented Architectures Service fulfillment Service assurance Service provisioning

1 Introduction Sophisticated and mature Operations Support Systems (OSS) as well as Business Support Systems (BSS) solutions already support and manage a wide range of network infrastructures, from small sized corporate to large sized operator networks. Many already existing OSS solutions can readily be utilized for the management of Next Generation Networks (NGNs), especially for managing the transport resource layer and partially for management of the Internet Protocol (IP) based service resource layer. However IMS-based NGNs require several adaptations and modifications to traditional OSS solutions. Due to the diversity of end-devices, access networks, traffic classes and due to the broad service landscape, there is the need for interoperable, open standard based solutions. NGN management solutions, for a long time, have not been appropriately addressed by NGN standardization groups, until recently, the Third Generation Partnership Program (3GPP) [1] as well as European Telecommunications Standards Institute’s (ETSI) / Telecommunications and Internet Protocol Harmonization over Networks, Services and Protocols for Advanced Networks (TISPAN) Compentence Centre [2] incorporated a first set of specifications for IMS-based NGN management into their current releases. The Fraunhofer Institute FOKUS has a broad expertise in the field of IMS [3–6], in particular IMS based NGNs [7]. Furthermore FOKUS actively participated in and contributed to the specifications of Telemanagement Forum’s (TMF) New Generation Operations Systems and Software (NGOSS) architectures, formerly the Telecom Operations Map (TOM) and currently the enhanced Telecom Operations Map (eTOM) [8]. Simultaneous to the release of the Open Source IMS Core (OSIMS), the globally unique OSIMS core system [7, 9], FOKUS has prototyped an NGN OSS solution for IMS based NGNs [10]. Due to several limitations, many traditional OSS mechanisms had to be improved or replaced by policy based, open, service and business oriented mechanisms that pave the way to enhanced levels of automation, self-healing, and self-provisioning. The initial and primary goals of FOKUS’ Next Generation Network Business and Operations Support System (NBOSS) approach were the implementation of fault management and service provisioning mechanisms for remote and automated supervision and management of various standard compliant IMS infrastructures, particularly emerging OSIMS-based NGN infrastructures. That is to say that although mainly targeted for managing OSIMS-based NGN infrastructures (OSIMS is based on 3GPP Release 6 specification), the presented approach is not limited to these only, but applicable to any standard compliant IMS infrastructure.

123


65

Since many concurrent standardization efforts address NGN OSS strategies, an in depth analysis of the major work in this area is provided in Sect. 2 of this document, together with new OSS challenges that come along with the proliferation of NGNs. The problem statement of Sect. 3 sums up requirements for supporting and managing NGNs, focusing on fault management and service provisioning. Section 4 describes achievements made by the integration of fault management components and is giving insight into innovative mechanisms for IMS-based service provisioning. After illustrating FOKUS’s NBOSS implementation as part of the OSIMSbased [11] IMS playground [6], new IMS based mechanisms for service lifecycle from automatic service deployment, NGN service provisioning, service to user advertisement and finally user agent based service execution are explained. The validation given in Sect. 5 illustrates initial results gained by the implementation of fault management and service provisioning mechanisms. As the NGOSS based NGN OSS solution explained in this document only covers aspects related to fault management and service provisioning (roughly depicted in Fig. 1), the outlook in Sect. 6 covers open issues and future work.

2 Motivation and State of the Art in Next Generation Network Management Appropriate OSS for NGNs, investigated within this work, requires broad reconsideration of traditional information technology as well as telecommunication operations management systems. After initially comparing legacy OSS approaches with NGN OSS requirements, this section sums up NGN OSS design principles and

Fig. 1 Focused NBOSS components for OSIMS based NGNs

123

66


objectives. Focusing on standardization efforts related to operation support systems for NGNs, conducted by ETSI TISPAN and 3GPP, the following subsections explain architectural principles of NGN OSS.

2.1 NGN OSS Versus Traditional OSS The challenges faced when adapting state of the art OSS solutions to NGNs are manifold. Apart from NGN specific components, protocols and traffic, future NGOSS based NGN OSS solutions have to deal with a huge diversity of end-devices, access-networks and services. Apart from that, multiple media types, multiple vendors, multiple domains, multiple users, multiple protocols, multiple Service Level Agreements (SLAs), compared to traditional telecommunication services short service lifecycles have to be managed and orchestrated economically and efficiently. In contrast to many proprietary BSS/OSS solutions, interoperability and unification of communication mechanisms towards service oriented management architectures are fundamental. Generally speaking, the capabilities of network elements have to be enhanced, allowing for improved self-management and selfawareness functionalities. Furthermore common, standardized languages for describing network element capabilities and an open, standardized, object oriented protocol for exchanging information from and to network elements has to be utilized. Fault management solutions for NGNs have to cover and supervise the full endto-end service delivery link, i.e. supervision of the user to network, user-to-user and user to service link is required. Only by supervising the end user perspective, service assurance mechanisms become efficient enough to provide an enhanced customer experience. Apart from utilizing Service Oriented Architecture (SOA) based design principles, several IMS/NGN specific adaptations to traditional OSS have to be conducted. Active and passive NGN performance and traffic monitoring tasks have to be capable of capturing and analyzing NGN specific traffic, traffic patterns, sessions and SLA specific traffic classes. Furthermore emulating NGN entities like user agents and application servers is required for actively probing network functionalities. IMS/NGN specific service provisioning mechanisms, apart from automated and unified configuration of a vast range of IMS/NGN components have to realize automation for the whole cycle from service deployment, service advertisement to service execution. In contrast to traditional IT infrastructure OSS approaches, telecommunications specific OSS mechanisms have to cover several additional management domains and tasks. Table 1 outlines extensions to the traditional OSS tasks, as specified by 3GPP. It shows a strong emphasis on supervision of the end-to-end perspective, where not only the user perspective, but also interoperability aspects between separate telecommunication network domains come into play.

123


67

Table 1 3GPP [1] extensions to ITU management tasks ITU’s traditional management tasks (FCAPS)

3GPP’s additional management tasks

Fault management

Roaming management

Configuration management

Fraud management

Accounting management

Software management

Performance management

User and equipment management

Security management

QoS management Subscriber and equipment trace management

2.2 NGN OSS And NGOSS Design Principles And Objectives In order to meet the requirements for IMS based NGN management, such as minimizing integration costs and maximizing automation, several design principles serve as a guideline. Implementation of policy based mechanisms, utilization of SOA principles and business driven service lifecycles providing a clear end-to-end view on customer’s experience are the cornerstones of NGN OSS architectures.

2.2.1 Policy Based Management Architecture Policy based management is a vital strategy for management of NGN infrastructures. Orchestration and management of multimedia, multi-service, multi traffic class, multi-user, multi-access network based architectures can only be conducted efficiently if system’s behavior can be adapted in real-time without requiring modifications to the programming logic. Figure 2 describes the Internet Engineering Task Force’s (IETF) and the Desktop Management Task Force’s (DMTF) [13, 14] fundamental components of a policy framework, where policies are being modified via a policy management tool/interface, stored inside of a policy repository, which is the source for the policy decision point. After appropriate actions have been retrieved from the policy repository, the decision is being forwarded to the policy enforcement point, which finally carries out the required actions. This simple framework allows for dynamic, real-time policy updates.

Fig. 2 IETF/DMTF policy framework (taken from [12])

123

68


Policies are rules that are determining the behavior of a system. A multi-user, multi-service network requires many decisions, which allow for dynamically adaptive, user-, end-device-, access network-, Quality of Service (QoS)-specific behavior. There are several categories of policies governing the behavior of an NGN, from security policies, QoS management policies, business rules, SLAs, to service/subscriber related policies. QoS monitoring for example has not only got to monitor all different kinds of coexisting traffic flows, but also, in order to validate SLAs crosscheck in real-time, whether subscriber specific service levels have been met. Depending on subscriber specific SLAs, measured QoS metrics might be acceptable or represent service degradation, which should either autonomously be resolved, reported or specific coping mechanisms should be conducted, all depending on policies. With every new service, service level and subscriber, these policies have to be modified and updated on all responsible management entities throughout the network in a dynamical manner. A management system for NGNs, including all different kinds of element managers and network managers has to integrate mechanisms for policy management on every instance of the architecture. By doing so, configuration, alarming, as well as fault management mechanisms can be conducted in an automated way that allows for highest element autonomy, minimizing reaction times, reducing network load as well as computational load of hierarchically higher management components.

2.2.2 Open, Standardized, Service Oriented Management Interfaces and Protocols In contrast to traditional IT infrastructures, where OSS mechanisms are conducted with focus on a specific network domain, the coexistence and interoperability of domain management systems can only be achieved by open, standardized communication mechanisms. Furthermore the key to integration of components in a multi-vendor environment for different types of networks is a common spoken language as well as common technology and implementation independent, interfaces and mechanisms. Lookup of a network element functionalities and interfaces should be made easy via repositories that host their descriptions. Execution and access to these interfaces can then be conducted in a plug-and-play manner.

2.2.3 End-To-End View On Customer Experience Not only ease of integration by utilization of harmonized interfaces plays an important role in the context of NGOSS based OSS mechanisms for NGNs. Another important factor is the supervision of customer’s experience by tightly monitoring the end-to-end QoS delivery. In order to supervise the connection between users and the NGN, as well as between users and (potentially externally hosted) services, extensive, distributed, active and passive monitoring mechanisms have to be conducted. Table 2 lists NGN specific objectives and NGOSS based solutions based on SOA and policy based design principles mentioned above.

123


69

2.3 Related Standardization Efforts There are several bodies responsible for standardization of NGN OSS architectures, protocols and mechanisms. ETSI TISPAN [2] reuses many NGN management concepts of 3GPP [1, 15] as well as implementation specific OSS mechanisms, like the Integration Reference Point (IRP) mechanisms (see Table 3)[16]. Apart from the liaison with 3GPP, ETSI TISPAN is putting emphasis on TMF New Generation Operations Systems and Software (NGOSS) framework [17], especially eTOM [8]. Furthermore the Organization for the Advancement of Structured Information Standards (OASIS) [18, 19] heavily promotes SOA based management approaches, paving the way for Web Services based solutions, which also slowly get recognized by ETSI as well as 3GPP (in [20] 3GPP conducted a feasibility study for Web Services based IRP solution sets, which showed the usability of Web Services as OSS interfaces for network elements). The International Telecommunication Union (ITU) NGN Management Focus Group (NGNMFG) tries to harmonize currently separated standardization efforts [21]. ETSI TISPAN NGN OSS architecture, can be regarded as the main reference point for the solution proposed in this work. Also ETSI strives for convergence of TMF NGOSS, ITU-T, 3GPP, and TMF Multi Technology Network Management (MTNM) [22] and IP Network Management (IPNM) [23] specifications. Table 2 NGN OSS objectives and solutions Objective

Solution

Management of NGN components from different vendors

Integration of standardized, universal protocols and mechanisms. Exploitation of Web Services based service oriented communication mechanisms.

Easy integration of new NGN components from different vendors

Utilization of standard application programming interfaces for network element management

Minimization of complexity

Unification of interfaces and protocols

Minimization of costs

Reduction of maintenance costs, by increasing the level of self-(healing, provisioning, awareness) mechanisms of network and management elements.Reduction of deployment costs by utilization of standardized plug-and-play mechanisn

Configuration capabilities that allow for rapid service deployment

Utilization of standardized, service oriented configuration interfaces and operations

Integrated fault management capabilities

Integration of fault management and self-healing mechanisms on every management layer and element.

Support for simplified remote management

Integration of standardized, configuration interfaces in a service oriented fashion.

Interoperability between Network operator and service provider

Integration of standardized management interfaces on every management layer for every managed element.

High scalability

Horizontal layered management architecture increases reusability of components

Unified name convention for managed network resources

Utilization of a standardized network resource model.

123

123

withdrawn

TS 32.175

CORBA

XML

TS 32.307

TS 32.305

TS 32.303

TS 32.304

+

+

TS 32.302

–

TS 32.111–5

TS 32.111–3

TS 32.111–4

+

+

TS 32.111–2

–

TS 32.111–1 TS 32.111

TS 32.600

Alarm FM

TS 32.301

Notification CM

TS 32.435

TS 32.415

TS 32.413

TS 32.414

+

+

TS 32.412

–

TS 32.409

TS 32.401

Performance Mgmt.

TS 32.667

TS 32.665

TS 32.663

TS 32.664

+

+

TS 32.662

–

TS 32.661

Kernel CM

TS 32.607

–

TS 32.603

TS 32.604

+

+

TS 32.602

–

TS 32.600

Basic CM

TS 32.615

TS 32.613

TS 32.614

+

+

TS 32.612

–

TS 32.600

Bulk CM

TS 32.317

TS 32.625

TS 32.623

TS 32.313

TS 32.624

TS 32.314

+

+

TS 32.312

–

TS 32.311

Generic CM

TS 32.325

TS 32.323

TS 32.324

+

+

TS 32.322

–

TS 32.321

Test Mgmt.

= Ongoing work, CM = Configuration Management, FM = Fault Management, IOC = Information Object Class, + = Explicitly specified, - = Implicitly specified or unspecified

SOAP

–

CMIP

Solution sets

-

Interface

TS 32.172

Information service

+

TS 32.141

Architecture

IOC

TS 32.140

Requirements

Subscription Mgmt.

Table 3 3GPP’s IRP standardization progress as at May 2007

70 J Netw Syst Manage (2008) 16:63–91


71

2.3.1 NGN Management in ETSI TISPAN The functional view of ETSI TISPAN, as shown in Fig. 3, differentiates several Service Interface Groups (SIG) of which the Transport Management (TM) SIG, the Service Resource Management (SRM) SIG and the Service Management (SM) SIG are the most important ones for this work. It defines Service Interfaces (SI) and SIG. SIs are ‘‘a well defined grouping of related NGN OSS Operations and constant data which are necessary to deliver coherent business or system functionality’’, as ETSI TISPAN puts it in [2]. A SI is regarded as a fundamental unit of standardization and is equivalent to the SOA service interface concept. A SIG on the other hand is seen as ‘‘a grouping of NGN OSS Service Interfaces that belong together according to a given logic or context.’’ The context of resources could either be linked to services or linked to new network capabilities. ETSI addresses the new challenges of NGN OSS by highlighting user, service, equipment multitudes as well as access diversity and nomadism. The Resource Management (RM) SIG is responsible for the management of the logical and physical service and transport infrastructure. The RM SIG enables the mapping of service-oriented information used by the Service Management (SM) SIG into resource/technology dependent information. In regard to the eTOM framework [8], the RM SIG can be mapped with the eTOM Resource Development

Fig. 3 TISPAN NGN OSS functional/information view in terms of NGN OSS Service Interface Groups (taken from [2])

123

72


and Management and RM and Operations process groupings. The RM SIG consists of two sub-SIGs: Transport Resource Management (TRM) and SRM. As TISPAN puts it, TRM SIG, corresponds to the traditional TM functions and handles the management of the transport layer. In addition to traditional management, it has several enhancements to support the transport layer of the NGN. The responsibility here is to establish the required connectivity and to configure other provisioned service related aspects in the NGN. These responsibilities include functions such as selection of network technologies, routing, network RM, inventories, etc. The TRM SIG includes functions like network to service alarm correlation, network access point configuration based on service profiles, enabling end-to-end IP-based connectivity configuration and assurance, Voice over IP (VoIP) infrastructure management, collecting service related network performance data on the network to enable service planning. Concluding, the TRM layer’s main functionalities and tasks are: selection of the network technologies, connectivity aspects, cross-network management function, Fault, Configuration, Accounting, Performance, and Security (FCAPS), provisioning of interfaces, network-to-service, alarm correlation and enabling end-to-end IP network configuration. Service Resource Management, as shown in Fig. 4, is like TRM a subset of RM. In contrast to TRM, the SRM SIG utilizes a new set of RM features to support the service layer of the NGN like management of applications, application data, users, user data, terminal equipment, and is responsible for the management of the implementation and logical infrastructure resources required to enable the services. TISPAN lists the following SRM SIG functions, as shown in Fig. 4: the mapping of the SM SIG requirements into service profiles and data interpretable by the underlying Element Management System (EMS) / Network Management System (NMS) and network nodes; the management of the application software and application data in the network, including introduction, upgrade, inventory, distribution, application technologies, open application interfaces and associated security mechanisms; the management of the end-user actions on his/her service profile: access by the end-user to his/her profile, the management of the impact on OSS systems following profile changes made by the end-user (customer selfmanagement); the management of the aspects related to Service Capabilities, such as presence, location, nomadism, and their impact on active services from the user perspective; the management of the aspects related to network capabilities, such as billing, routing, etc.; the management and mechanisms to support subscription to services and the management of the subscription by the end user (self management); the management of the subscriber data and user profile database and its content; the collection of service delivery SLA data in order to guarantee that services are delivered with the requested quality; the collection of service performance data and its analysis to enable input to service resource planning functions; the management of the service required software and configuration on Customer Premise Equipment (CPE); the management of the system allowing for CPE management; the management of the pre-testing of the service; the management of the application redundancy policy; the management of the re-dimensioning of the infrastructure in case the service needs to be extended; the management of the collection of application performance data.

123


73

Fig. 4 NGN OSS tasks and NGN topology (based on [2])

Summarizing, SRM is responsible for the management of the implementation and logical infrastructure of resources required to enable the services in a technology dependent manner and allowing for such features like user actions on their service profile, service pre-testing or configuration of the billing infrastructure. The Service Management (SM) Service Interface Group (SIG), as shown in Fig. 4, consists of management functions regarding the service development, management and operations. Examples of these are the delivery of service capabilities, service configuration, service problem management, service rating, service quality analysis and management. The typical management tasks of SM SIG include the management of the services from an end-to-end perspective, the management of service profiles and the management of the association of actual subscribers to the set of profiles corresponding to this subscribers service contract (Initial Filter Criteria management), the supervision and proactive management of services to guarantee contractual SLA(s), management of service usage records. It is important to notice that all functions within the SM SIG will be resource and technology independent and will provide no knowledge about the underlying

123

74


resources involved in the provisioning of services. In particular, no information about transport or service platforms will be provided in the SM SIG. According to TISPAN, the SM SIG relies on the RM SIG to map its service oriented view and information to the required resources. Apart from the three SIGs mentioned above, the ETSI TISPAN concept differentiates between five other SIGs, which do not play a major role in the FOKUS Open IMS NGN OSS solution at this state of development, but are of interest in the future. These SIGs are Market, Product and Customer Management (MPCM), Basic Framework Services (BFS) SIG, Supplier/Partner Management (SPM), managed NGN service resources and managed NGN transport resources. The MPCM concentrates on the customers facing aspects of OSS and the field of service ordering (order intake) and self-management, for instance applicable to user profile management. The identification of the NGN OSS service interfaces related to the MPCM SIG is for further study. Figure 2 summarizes the TISPAN NGN OSS architecture.

2.3.2 NGN Management in 3GPP 3GPP, specifies a management reference model as depicted in Fig. 5. A number of management interfaces are defined; the most important of them being type 2 and type 1. (Type 4 and 6 are quoted as being beyond the scope of standardization, type 3, 5 and 5a are for further study). Type 2 interfaces, between the Element Manager (EM) and the Network Manager (NM) of a single organization, have the reference name ‘‘Ift-N’’ (the Network Interface) and are the main standardization target. The interface of type 2 hosts the implementation of the IRP. The type 1 Network Element (NE) management interfaces allow the use of certain management application protocol suites, with Web Services as the new application protocol suite being considered. An important concept regarding 3GPP telecommunication management is an IRP depicted in Fig. 6 [16]. The IRP concept takes a top-down, process driven modeling approach, specifying one task at a single point in time. The goal of the IRP concept is to create an interface technology independent model, separating implementation specific mechanisms from open, unified interfaces for data exchange. Fundamentally, the IRP concept assumes standard-based modeling which is technology dependent. The result of this approach is the creation of one or many IRP Solution Sets. Figure 6 illustrates the 3GPP IRP components. While the IRP requirements include use case definitions and conceptual definitions according to unified modeling language approaches, the information service differentiates three components. The interface IRP specifies operations and notifications in a protocol-independent and network-neutral way. The Network Resource Model (NRM) relates to a specific network, but is still protocol independent, followed by a network aware data definition still without relating to a specific protocol. Finally the solution set specifies a dedicated protocol for data exchange. Here several different approaches are supported by 3GPP standards, such as the Simple Network Management Protocol (SNMP), Common Management

123


75

Telco Enterprise Y

Telco Enterprise X

5

Enterprise Systems 3

3

Network Manager (NM)

NGN OSS

2

2

Domain Manager (DM)

4

Network Manager (NM)

2 Domain Manager (DM)

Domain Manager (DM)

4a

5a

Element Manager (EM)



1

1

1

Network Element (NE)

Network Network Element Element (NE) (NE)

Network Element (NE)

6

5

2

EM NE

Fig. 5 3GPP management reference model [1]

Information Protocol (CMIP), Common Object Request Broker Architecture (CORBA) and Simple Object Access Protocol (SOAP). The clear trend regarding IRP solution sets are eXtensible Mark-up Language (XML) / SOAP based Web Services, since they are simpler to implement than CORBA object oriented interfaces, allowing for a repository lookup, bind and execute based approach, which is the basis for vendor independence and plug and play [20]. In addition to the concepts mentioned above, 3GPP calls for an open systems architecture when designing management solutions. This goal can be achieved by focusing on widely recognized and supported interface standards. The reuse of standardized technologies should contribute to ensuring the costs and quality of the management products [15]. 3GPP telecommunication management initiative takes into consideration business needs and requirements. Initially, the business needs are the basis for the definition of the functional architecture. This part of the whole system has the responsibility of describing the functions that need to be achieved. As a next step, the information required for achieving the functions, presented in the functional architecture, has to

123

76


Fig. 6 3GPP IRP concept (cmp. [16])

be provided by the definitions of the information architecture. The physical architecture has to meet the requirements of both the information and functional architecture. Figure 7 shows the telecommunication management architectural dependencies [1]. 3GPP refers to eTOM and defines the following management functions: Performance management, Roaming management, Fraud management, Fault management, Security management, Software management, Configuration management (CM), Accounting management, Subscription management (SuM), QoS, User equipment management [1]. The current FOKUS Open IMS NGN OSS solution focuses mainly on two management functions: fault management and SuM, however with close relations to performance management, CM and user equipment management.

Fig. 7 3GPP telecom management architectural relationship (taken from [1])

123


77

3 Design Issues of Next Generation Network Management In the simplest scenario an operator has to manage a single NGN domain. However, as the work at FOKUS has shown, management of several domains and NGNs simultaneously is more common. Therefore an increased level of automation is necessary in order to help to more efficiently manage human resources and to keep manual intervention times as short as possible. Every system has to implement a kind of fault resolution mechanism for self-healing. Ideally this should be made extensible in order to accommodate for future action. Furthermore this mechanism should be capable of incorporating previously, successfully conducted human actions into the decision process in order to ensure improved self-healing capabilities. NGN service and user provisioning is subject to continuous change. Hundreds of new services and users have to be provisioned, service and user preferences and profiles need to be modified, and furthermore users should be able to be de-provisioned and services to be removed from the NGN easily and cleanly. Given this, NGN operators have to struggle with many issues regarding the provisioning process. Another aspect related to NGN management is the increased importance of interoperability between many different players in the telecommunication market. Not only must NGN operators and service providers be able to manage their own infrastructure, but they also need to tightly cooperate with their external third party service providers [1]. The increased complexity of NGN infrastructures moving towards 4G, multiaccess, multimedia, telecommunication infrastructures and services is another important factor. Therefore ETSI TISPAN requires NGN service provisioning mechanisms to provide a holistic information model and to hide the complexity of the network element about to be provisioned [24]. According to OASIS Provisioning Services Technical Committee, one of the biggest issues with service provisioning mechanisms is the adoption of diverse protocols and approaches, which is a challenge for both service provisioning vendors and designers of provisioning systems. The whole industry would benefit, if a higher level of standardization would be brought to bear on this problem [18]. Apart from that, by utilization of unified and harmonized communication mechanisms for NGN service and user provisioning, a vendor lock-in can be avoided. From the list of management tasks given in Table 1, the current state of this ongoing work at FOKUS only covers NGN fault management and provisioning/ configuration aspects. Primary goals of NGN fault management systems are minimal, ideally zero downtime, as well as minimal, ideally zero required human intervention for fault resolution. Similarly, network resource, as well as service resource provisioning aims to automate service as well as subscriber related provisioning and configuration tasks as much as possible, minimizing the demand for human interactions. Only if these management goals are fulfilled appropriately, telecommunication service providers are able to achieve high quality service assurance with minimal administrative overhead.

123

78


Similar to what the telecommunication industry currently experiences as a paradigm shift away from stovepipes towards horizontally layered service delivery infrastructures, many OSS concepts which traditionally were applied have to be rethought. In order to meet these goals, two design principles of OSSs for NGNs have to be highlighted. The proliferation of SOA based NGN management architectures and the utilization of object oriented protocols with service discovery, subscription and notification capabilities, allowing seamless integration of 3rd party components and services in a plug and play manner. This means that the logic and intelligence of many network elements and EMs has to be enhanced, in order to perform selfhealing, self-provisioning, self-monitoring tasks. The adoption of policy-based mechanisms is the second most important pillar of lean and efficient NGN management. Rules can dynamically be introduced and modified, in order to regulate the behavior of the network. These policies control fault management, load balancing, subscriber treatment, traffic prioritization and many more aspects responsible for the network behavior during live operation. These policies control the behavior of network elements, as well as EMs and NMSs. The more insight a management component has about the current state of the network, the more sophisticated these rules get. By integration of self-healing mechanisms on every network element of the NGN, times of failure can be minimized. Every network element should be capable of analyzing its own processes and detecting its own vital states. As long as the network element is capable of resolving its own problems, it should do so autonomously. Only if a network element detects a problem which it cannot resolve by itself it should disseminate alarms towards management components (domain or network managers) of higher hierarchical layers.

4 Fokus Next Generation Network Business and Operations Support System Achitecture The two focused NGN management functionalities (provisioning and fault management), approached in this work, already give fundamental insights into the scope of distributed management mechanisms for NGNs. The general communication between network/domain managers and element management entities, as it also applies to service provisioning mechanisms, is a pull model, where the central management instances initiate communication with the distributed EMs. Only one NGN OSS communication mechanism, which is fault management, is initiated by EMs, pushing notifications and alarms to the centralized domain/ network managers. Figure 8 shows the basic composition of a managed NGN element manager. Several IRPs have already been standardized, as depicted in Table 3. Usually a network EM includes several IRPs, dedicated to different functional NGN management aspects. For service/subscriber provisioning, managed network elements are equipped with notification IRPs, basic CM IRPs. Furthermore for active configuration management, state management IRPs, as well as SuM IRPs

123


79

IRP Managers

M&C Server

Provisioning Server Itf-N Network Interface

Element Manager IRP Agent Test Measurement IRP

Generic IRP

Log IRP

Basic CM IRP

Notification CM IRP

Bulk CM IRP

Alarm FM IRP

Subscription Management IRP

Performance Management IRP

Itf-P2P Peer to Peer Interface

Network Elements

AS

HSS

P-CSCF S-CSCF I-CSCF

XDMS

Fig. 8 An element manager with a set of different IRPs

have to be deployed. For fault management, alarm IRPs, basic configuration IRPs, test management IRPs and performance management IRPs are utilized. Table 3 lists the progress made by 3GPP IRP specifications. Whereas the requirement and information service layer have already been covered, there is still further work required on Web Service solution sets. Here we followed the strategy of using already specified SOAP IRP solution sets and implemented proprietary ones for yet not specified SOAP IRP solution sets. In the context of SOA based NGOSS compliant interface standardization, TMF adopted the OSS through Java (OSS/J) API [25]. As [26] shows, there is a close alignment of the OSS/J API and 3GPP IRP in several management domains. In the case of fault and performance management, utilization of OSS/J APIs is already suitable for delivering IRP

123

80


requirements. Therefore Web Service based OSS/J communication is utilized where applicable.

4.1 Fault Management Architecture In the context of TRM and SRM SIGs, service availability, as well as QoS, i.e., service assurance, is the primary goal of NGN fault management mechanisms. In order to minimize downtimes and increase service quality, constant supervision and monitoring of the service delivery performance and quality is required. Especially in the context of IMS based multi-user, multi-SLA, multimedia NGN environments, sophisticated fault management mechanisms are key for service assurance. In order to constantly monitor network, device and service quality, the implemented fault management architecture obtains performance measurement from active and passive resources, as shown in Fig. 9 as IMS traffic generator and IMS traffic collector. Furthermore local agents, deployed on IMS components constantly supervise IMS processes and device states. In close alignment to 3GPP who also realized that adequate fault management can only be delivered by utilizing additional performance measurements. Therefore subtle fault prediction mechanisms require long term monitoring and trend analysis of IMS traffic and IMS device information. Policy based thresholds for triggering alarms or self-healing mechanisms are deployed on the central Monitoring and Control (M&C) domain

Fig. 9 M&C Server functional components and interfaces

123


81

managers, as well as on network elements. Based on these policies, events are being triggered in order to resolve conflicts, restart components, throttle access or block connection attempts.

4.1.1 Active Probing with User Agent Emulation In contrast to distributed passive traffic measurement and analysis, active probing mechanisms represent a straight-forward mechanism to test session control layer and service delivery platform (SDP) functionalities. By generating real time, standard compliant IMS traffic, several fundamental network capabilities are being tested for and performance analysis is being conducted based on these tests. The basis for the user agent emulator is FOKUS Open IMS Client (OpenIC) [27]. Basically the extensions added customizable routines in order to precisely control the actions of the emulated user agent and support for multiple users. Perpetual traffic generation, as well as on demand active testing can be conducted. Apart from that, extensive logging capabilities are provided in order to aid in error detection and traffic analysis. The user-agent emulator is integrated into the FOKUS Open IMS Playground [7] as a standalone component as well as a module of the FOKUS M&C architecture [6]. Application server emulation, the second component of the emulation architecture, is implemented in order to assess the performance of IMS core functionalities (i.e., IMS routing and Home Subscriber Server functionalities) that deal with user profiles and initial filter criteria.The following Fig. 10 shows the threefold active testing mechanism that can be conducted with the emulator. First, User Agent (UA) to IMS Core connectivity (the User Network Interface UNI) by means of basic messaging (e.g., registration) is being tested for on a periodic basis. Second, the user agent to user agent session establishment by sending invitations periodically is being tested for, and finally user agent to application server connection by sending invitations and subscriptions is frequently checked.

4.1.2 Active and Passive Traffic Collection Sophisticated traffic capturing, collection, correlation and analysis mechanisms provide real-time information about the current network state. Whereas local network elements do only possess a minimal view about the current state of the network, centralized collection and correlation of network and traffic information provides an extensive view on the current network status. In contrast to passive traffic measurements, active probing allows for on demand testing of specific network functionalities and on demand performance analysis. Whereas passive measurements rely on current network load, active tests can be conducted, whenever necessary. Active tests, however, alter the current state of the network, by putting extra load on the network. Therefore active probing should be used in conjunction with passive analysis for full efficiency.

123

82


Fig. 10 The NBOSS Traffic Emulation

In contrast to active probing mechanisms, passive traffic analysis can be performed any time. Network performance analysis, service quality analysis and security analysis are only some of the tasks, conducted by utilization of passive traffic collection and correlation. In the NBOSS architecture fully transparent network taps, that basically act like network proxies are utilized for traffic capturing, as shown in Fig. 11. When dealing with encrypted traffic (at sensitive points in the network), these network taps have also got to be equipped with decoding functionalities in order to encrypt the incoming and outgoing traffic for further analysis. IMS core performance tests differentiate processing and transmission delays. Processing and transmission delays make up the overall signaling delay of the session control layer. Deterioration of the session control signaling performance, not only results in deterioration of user perceived service quality alone, but also stresses IMS core due to unnecessary retransmissions. In order to distinguish and measure both processing and transmission delays, distributed passive measurements must be correlated and analyzed efficiently. Processing time starts when the messages are received and ends when they are forwarded to the next entity. In contrast, transmission time starts when messages are dispatched and ends when messages are

123


83

Fig. 11 Transparent Network taps for passive traffic analysis

received at the network interfaces of network devices. Whereas an increased processing time usually relates to an increased system load, an increased transmission time usually relates to network anomalies or routing troubles. Precise time synchronization of all participating NGN entities is fundamental for successful, distributed traffic and device information correlation. By utilization of a single Global Positioning System (GPS) enabled stratum ‘‘0’’ Network Time Protocol (NTP) server synchronization of all participating NGN components is conducted with a maximum deviance of +/-3 ms of each system clock. Root cause analysis, also known as fault localization, is a highly complex task in many cases. Apart from simple scenarios, where only a few components play a role in the signaling flow, complex scenarios with several participating network entities require extensive analysis of captured traffic information, results from active network probes and real-time device information.

4.1.3 IMS-Based Service and User Provisioning In the context of ETSI TISPAN SM SIG, for NGN service fulfillment, sophisticated user (subscriber) and service provisioning mechanisms are required. The provisioning server is the central component for conducting configurations on network elements. It is capable of provisioning Home Subscriber Servers (HSSs) which maintain the service and user profiles in a secured way. Furthermore the provisioning server comprises of Web SI which can be exploited for configuration of service related service enablers, like the XML Document Management Server (XDMS) [28], Online Charging Servers (OCS) or data synchronization (DS) servers.

123

84


The Open Mobile Alliance (OMA) [29] standardizes several IMS/NGN-based service enablers from presence servers, XDMSs, Device Management (DM) servers [30], to DS servers. The central provisioning entity in order to configure and provision for new services and subscribers not only communicates with HSSs and service enablers but also is capable of configuring and administering policy repositories. The policy enforcement and evaluation manager (PEEM), the most fundamental component of the OMA Service Environment (OSE) [31] maintains one of the most important policy repositories. Based on these policies the PEEM coordinates communication between (third party) services and service enablers allowing for policy based access authorization and service composition. Following the fundamental concept of 3GPP decomposition of functionalities for increased flexibility and scalability; one Proxy/Interrogating Call Session Control Function (P/I-CSCF) combination per user can interconnect with many Serving Call Session Control Function (S-CSCFs) via Service Locator Functions (SLF); one private identity allows for several public identities; and following the OMA concept of reusability of OSE service enabling components, the already existing and standardized service enablers like group list management (XDMS functionality) are exploited in order to dynamically provide users with applicable service information. Furthermore data management which is based on Synchronized Mark-up Language (SyncML) [32] is used to check whether a specific service requires any device specific software update or configuration. In those cases where authorization permits, subscribers as well as third party service providers should be given the ability for self-provisioning. Some design issues still remain. In order to allow for third parties to configure the PEEM it is required that the PEEM forwards service deployment/provisioning requests from third-party service providers to the provisioning server, as depicted in Fig. 12. Furthermore the provisioning server is capable of configuring the PEEM in order to modify and update PEEM policies, depicted in Fig. 13, which enables the thirdparty service provider to automatically reuse service enabling functionalities. User provisioning and de-provisioning has to deal with managing IMS users and providing functionalities like adding, searching, modifying and removing user profiles. Service provisioning, on the other hand, deals with the management of NGN services with the emphasis on automation of the processes. The service and user provisioning functionality of the FOKUS NBOSS solution is based on SOA principles, which in regard to NGN management enables rapid and economical implementation of new functionalities and therefore makes it possible to quickly adjust to the constantly changing requirements of the telecommunication environment and customer needs. The Provisioning Server provides a Web Services interface for triggering Services Provisioning Markup Language (SPML) [19] requests. Administrators edit the profile of a new user and send provisioning requests to the provisioning server. The provisioning server validates the administrative requests, creates a set of SPML [19] requests and forwards them to the network entities that are to be provisioned with user profile or service profile information. Network elements are equipped with interfaces which translate SPML into the target specific

123


85

3rd Party AS

3rd Party Services Service Delivery Platform

PEEM

Device Mgmt

XDMS Provi Srv

UA

Fig. 12 PEEM decoupled Integration of the provisioning server

operations. These are primarily Structured Query Language (SQL) statements which are triggered on the network element databases. Figure 14 demonstrates the dynamic service provisioning architecture as prototyped at FOKUS. Automatically after registration, the user agent retrieves a list of applicable services from an XDMS. When a new service is being deployed, it triggers the service provisioning mechanisms, conducted by the provisioning server (here only XDMS and HSS are depicted). Automatically the XDMS notifies the user agent about applicability of a new service. If the user is interested in a service, he first has to subscribe for it (SIP Subscribe). Again automatically user/service provisioning mechanisms are being conducted, updating user profiles on the HSS, synchronizing/updating software on the end-device (if necessary) and finally setting the service active on the XDMS, which consecutively notifies NGN users about service activation.

5 Validation The NBOSS architecture discussed in this document has been implemented on top of OSIMS as part of the Open IMS Playground [7]. With the help of this solution

123

86


3rd Party AS

3rd Party Services Service Delivery Platform

PEEM

MGT Srv Device Mgmt

XDMS Provi Srv

UA

Fig. 13 PEEM coupled integration of the Provisioning Server

administrators are informed about occurring failures within seconds either by e-mail or by Short Messages Services (SMS). The most suitable technique in order to quickly detect any occurring faults of the IMS Core components is actively probing IMS Core functionalities (P/I/S CSCF and HSS functionality) with different SIP methods. Figure 15 shows that with probing for successful IMS registrations (SIP Register), an HSS fault is detected within 10 ms, whereas S-CSCF and I-CSCF errors are only detected 10 s (for S-CSCF faults) or 30 s (for I-CSCF faults) after a registration test has been conducted, which is insufficient. The reason for that is related to IMS core specific re-transmission parameters and internal time-outs. For actively testing P/I/S CSCF functionality, OSIMS [5] CSCFs have been equipped with an echoing functionality, similar to the Internet Control Message Protocol (ICMP)–Echo method. Actively sending a SIP OPTIONS message to the P/I/S CSCF allows for timely fault detection. As shown in the following figure, all vital CSCFs usually respond within 10 ms to the SIP OPTIONS method. A combination of different active tests, i.e., sending periodical registrations as well as SIP-OPTIONS, allows for fault detection of any IMS Core component within 10 ms. The policy based, self-healing process, conducted after fault detection, is capable of resolving conflicts within 10 ms. Therefore the overall

123


87

Fig. 14 Automated lifecycle from service deployment to service execution

fault detection delay is mostly determined by the testing frequency, which should not be chosen too high in order not to perturb the overall system performance. In our case the testing frequency was set to 200 ms, resulting in 5 IMS Registrations and 15 IMS/SIP-OPTIONS tests per second. As a result, the maximum overall fault detection delay amounts to 220 ms. Currently 9 out of 10 failures (mainly IMS Core deadlocks) are being handled in an automated (self-healing) way without the necessity of human intervention. This performance is constantly being improved by updating new policies for fault management network elements as well as network/ domain managers. Nevertheless, a history of fault resolutions mechanisms conducted in the past is being created and, depending on severity, messages are being sent, by e-mail and/or SMS to administrators. Service/Subscriber mechanisms

123

88


Fig. 15 Fault detection delay for REGISTRATION and OPTIONS tests

greatly reduced administrative overhead, since formerly many IMS Core as well as service enabling components had to be configured separately and manually as soon as new users or new services had to be provisioned for. Since the FOKUS Open IMS Playground [7] comprises of all major IMS service enablers, after integration of the provisioning service enabler it is easy to conduct the automated service deployment, advertisement and execution lifecycle.

6 Summary and Outlook This document discusses two fundamental OSS mechanisms for NGNs. In the context of service assurance, Open IMS Playground [7] implementations for fault management were described and early results from deployments were explained. For service fulfillment, experiences made by implementing and utilizing NGN user and service provisioning mechanisms were explained. Both implementations utilized Web Service based communication mechanisms, aligning closely with current NGN management standardization efforts. Thereby the feasibility of such an approach was approved. Further findings realized benefits of active and passive NGN fault management approaches, showing benefits and efficiency of policy based, automated self-healing mechanisms. In the context of NGN user and service

123


89

provisioning mechanisms the key finding was that by utilizing already applicable OMA service enablers, a high degree of automation of service and subscriber provisioning was realized. The Fault management solutions and service provisioning mechanisms for NGNs explained in this document are neither exhaustive nor sufficient for future IMS-based NGNs. Nevertheless, with the help of the addressed fault management functionalities, deadlocks, times of failure and situations of network overload were greatly reduced. Robustness and reliability of OSIMS based NGNs improved remarkably. The mechanisms for IMS-based service provisioning allow for convenient, centralized NGN service configuration and paved the way for a new IMS-based concept for automated service deployment, service advertising and execution. NGN users are now instantaneously, automatically and dynamically being informed about the applicability and characteristics of recently deployed NGN services. Whereas we currently implement OSS/J interfaces for fault management and Web Service based solutions for the management of network element configurations (i.e. provisioning), next steps will be integration of OSS/J performance management application programming interfaces. Utilization of the already existing passive network taps for security management will soon allow for IMS intrusion and fraud detection with appropriate mitigation and counteraction mechanisms. Device management (i.e. 3GPP User endpoint management) mechanisms, including enddevice based self-provisioning, user endpoint based QoS monitoring as well as white-pages of applicable IMS services with an appropriate ontology for service description are currently under development. What is currently missing and heavily under investigation is an appropriate information/data model for IMS/NGN services. With the help of such an information model, the various network elements and service enablers that are required for compositional services as well as network resources can seamlessly be provisioned for. Subscribers will also benefit from such a service information model, allowing for a consolidated view on service capabilities and requirements. The future work in the context of FOKUS NBOSS architecture will heavily make use of SOA concepts and provide enhanced manageability not only for the session control layer functions of the Open IMS Playground [7], but more and more for the Open SOA Telco Playground [33], which provides an extensive testbed for prototyping and testing telecommunication SDP architectures. Knowledge attained from prototyping and evaluating SOA based NGN service composition and SM systems, will be submitted for standardization to the Autonomic Communication Forum [34].

References 1. 3GPP TS 32.101, Telecommunication management, principles and high level requirements, http://www.3gpp.org/ftp/Specs/archive/32_series/32.101/ 2. ETSI TS 188.001, NGN management, operations support systems architecture 3. Witaszek, D., Carvalho de Gouveia, F., Wahle, S., Magedanz, T.: IMS playground in pan-European network of testbeds, 3rd International Conference on Testbeds and Research Infrastructures for the Development of Networks and Communities (TridentCom 2007), ISBN: 1-4244-0739-7, Orlando, Florida, USA, 21–23 May 2007, http://www.tridentcom.org

123

90


4. Vingarzan, D., Weik, P., Magedanz, T.: Design and implementation of an open IMS core, In: Proceedings of Mobility Aware Technologies and Applications: Second IEEE International Workshop, MATA 2005—Service Delivery Platforms for Next Generation Networks, Montreal, Canada, 17–19 October 2005, ISBN-13: 978-3540294108,Springer, Berlin (Lecture Notes in Computer Science 3744), pp. 284–293, October 2005 5. Open Source IMS Core OSIMS, http://www.openimscore.org 6. Open IMS Playground—IMS Management toolkit, http://www.open-ims.org/ims-mgmt 7. FOKUS Open IMS Playground, http://www.open-ims.org 8. Telemanagement Forum, GB921, Enhanced Telecom Operations Map (eTOM), The Business Process Framework for the Informations and Communications Industry, Release 6.0, Version 6.1, November 2005 9. Vingarzan, D., Weik, P., Magedanz, T.: Development of an open source IMS core for emerging IMS testbeds, the academia and beyond, special issue on IMS, J. Mob. Multimedia (JMM), 3(2): 131–149, Rinton Press, Princeton, USA, June 2007, http://www.rintonpress.com/journals/jmm 10. Dinu, F., Jacak, P., Blum, N., Schreiner, F., Magedanz, T.: Automated service provisioning and fault management for OSIMS based NGNs. In: Proceedings of the 14th Annual Workshop of HP Software University Association, 2007, ISBN-13: 978-3-00-021690-9, pp. 271–276, Infonomics–Consulting, Stuttgart, Germany, July 2007 11. Weik, P., Vingazan, D., Magedanz, T.: Towards an open source IMS core system enabling rapid prototyping of NGN services, 3rd international workshop on ‘Next Generation Networking Middleware’ (NGNM06), ISBN: 972-95988-7-8, Coimbra, Portugal, 19 May 2006 12. Verma, D.C.: Simplifying network administration using policy-based management, Network, IEEE, 16(2), 20–26 April (2002) 13. Moore, B., Elleson, E., Stassner, J., Westerinen, A.: Policy core information model version 1 Specification, Request for Comments 3060, Internet Engineering Task Force, February 2001 14. Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.: Terminology for policy based management, Request for Comments 3198, Internet Engineering Task Force, November 2001 15. 3GPP TS 32.102 Telecommunication management, Architecture, http://www.3gpp.org/ftp/Specs/ archive/32_series/32.102/ 16. 3GPP TS 32.150, Integration Reference Point (IRP) Concept and definitions, http://www.3gpp. org/ftp/Specs/archive/32_series/32.150/ 17. Telemanagement Forum, New Generation Operations Systems and Software (NGOSS) Overview, http://www.tmforum.org/browse.asp?catID=1912 18. OASIS Provisioning Services TC, http://www.oasis-open.org/committees/provision/faq.php 19. OASIS, OASIS Service Provisioning Markup Language (SPML) Version 2, OASIS Standard April 1, 2006, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=provision 20. 3GPP TR 32.809, Telecommunication management, Feasibility study of XML-based (SOAP/HTTP) IRP solution sets, http://www.3gpp.org/ftp/Specs/archive/32_series/32.809/ 21. ITU-T SG4, NGN management Specification Roadmap, January 2007, http://www.itu.int/ITU-T/ studygroups/com04/docs/roadmap_pdf.zip 22. Telemanagement Forum, Multi-Technology Network Management Solution Set Document, TMF 814, Release 3.5, Version 3.1, March 2007 23. Telemanagement Forum, IP Network Management Information Agreement, TMF 611, Release 1.0, Version 0.6, December 2005 24. Draft ETSI DTS 188 002 v0.0.6, TISPAN, NGN Management, Subscription Management Requirements 25. The OSS through Java Initiative (OSS/J), http://www.ossj.org 26. Raymer, D.: Statement of alignment between OSS through Java Initiative and 3GPP, Version 1.1, Motorola, December 2004, http://www.ossj.org/learning/docs/wp_statement_ossj_1.1.pdf 27. FOKUS Open IMS Client, http://www.open-ims.org/openic 28. Open Mobile Alliance, XML Document Management Architecture, Version 1.0, June 2006 29. Open Mobile Alliance, http://www.openmobilealliance.org/ 30. Open Mobile Alliance, Device Management Requirements, Version 1.2, February 2007 31. Open Mobile Alliance, OMA Service Environment, Version 1.0.4, February 2007 32. Open Mobile Alliance, SyncML Device Management Protocol, Version 1.1.2, December 2003 33. The Open SOA Telco Playground @ FOKUS, http://opensoaplayground.org 34. The Autonomic Communications Forum (ACF), http://www.autonomiccommunication-forum.org

123


91

Author Biographies Niklas Blum is the Deputy Director of the Next Generation Network division at the Fraunhofer Institute FOKUS, which also provides the national NGN/IMS test and development centre in Germany. His expertise is based on distributed communication systems, advanced middleware technologies, VoIP, IP-Multimedia Subsystem and Service Orientated Architectures. He is a frequent speaker at conferences giving speeches and full-day tutorials related to his research topics. He also publishes research papers in his fields of expertise. Niklas Blum holds a Master degree in Computer Sciences from the University of Applied Sciences at Leipzig in Germany and currently works on his PhD thesis related to SOA in telecommunications. Piotr Jacak is a student assistant at the Next Generation Network division of the Fraunhofer Institute FOKUS in Berlin. He is currently writing his diploma thesis in the field of user and service provisioning for Next Generation Networks / IP Multimedia Subsystem (IMS) under the supervision of Prof. Dr. Thomas Magedanz and Peter Weik. His interests are NGN user and service provisioning and software engineering. Florian Schreiner is a senior research engineer at the ‘‘3G beyond’’ division, the Competence Center Next Generation Network Infrastructures (NGNI) at the Fraunhofer Institute FOKUS. He holds a M. Sc. (Dipl.-Ing.) in Electrical Engineering from the Technical University of Berlin. His major areas of expertise are mobile and fixed mobile convergent applications and media for IP Multimedia Subsystem based Next Generation Networks, signaling protocols in IP-based networks and Operations Support Systems for Next Generation Networks. He currently works on his PhD in the field of SOA based Next Generation Network Operations Support Systems. He worked for several national and international research projects and published several papers in his field. Dragos Vingarzan followed the academic programs of the Automatic Control and Computers Faculty at the Politechnica University of Bucharest and between 2001 and 2004 he was in parallel leading the software department of the ISP Romania Data Systems. Since then, he works at FOKUS as a PhD student where he is the architect of the Open IMS Core and is leading the signaling components developments and performance evaluations. As an active member of several NGN benchmarking standardization efforts, his main field of interest is performance evaluations, analysis, proof-of-concepts and improvements for IMS as well as the development of monitoring tools for NGNs. Peter Weik graduated in ‘‘Industrial Engineering and Management Science’’ at the University of Karlsruhe, Germany with specific emphasis on Telematics and Telecommunication networks. Since 2004 he is working in the FOKUS team ‘‘Next Generation Network Infrastructures’’ as a PhD student where he is actively involved in the realization and development of the Open IMS Playground and Open SOA Telco Playground and in various national and international research projects. He is a frequent tutorial speaker at conferences and published and presented several papers in the field of IMS and NGNs. His current field of research (besides the work on the HSS for the Open IMS Core) is in the development of dynamic service provisioning and identity management solutions for NGNs.

123