Alex1998(Technical Product Description)

221 02-FGC 101 302 Uen C 2006-03-14

Ericsson IP Service Engine 2.0 Technical Product Description


2 221 02-FGC 101 302 Uen C 2006-03-14

Copyright Copyright © 2006 Telefonaktiebolaget LM Ericsson

Disclaimer All rights reserved. No part of this material may be reproduced in any form without the written permission of the copyright holder. Due to continued progress in methodology, design and manufacturing, the contents of the documents are subject to revision without notice. Ericsson assumes no legal responsibility for any error or damage resulting from the use of this document.

Trademark List Ericsson Ericsson is the trademark or registered trademark of

Telefonaktiebolaget LM Ericsson. All other product or service names mentioned in this manual are trademarks of their respective companies.


221 02-FGC 101 302 Uen C 2006-03-14 3

Contents 1 Introduction..................................................................................................... 5 1.1 Purpose.......................................................................................................................... 5 1.2 Scope ............................................................................................................................. 5 1.3 Audience ........................................................................................................................ 5 1.4 How This Document is Organized ................................................................................. 5 1.5 Conventions Used in This Document ............................................................................ 6 1.6 Related Documents ....................................................................................................... 7

2 Background..................................................................................................... 9 2.1 Current Market ............................................................................................................... 9 2.2 IPSE Perspective ........................................................................................................... 9 2.3 Concepts ...................................................................................................................... 10 2.4 IPSE 2.0 Policy-Based Framework.............................................................................. 15

3 IPSE Functionality ........................................................................................ 19 3.1 End-to-End Operations ................................................................................................ 20 3.2 Scenario 1: Dynamic Control of IP Services................................................................ 29 3.3 Scenario 2: Static Provisioning of IP Services............................................................. 34 3.4 Engine MultiMedia (EMM)............................................................................................ 37 3.5 EDA Provisioning Solution ........................................................................................... 41 3.6 Web Services Layer..................................................................................................... 45 3.7 Self-Service Portal ....................................................................................................... 46 3.8 Broadband Remote Access Service (BRAS) Functions .............................................. 47 3.9 Flow-Through Provisioning .......................................................................................... 56 3.10 Service Management ................................................................................................... 59 3.11 Policy Management ..................................................................................................... 61 3.12 Session Management .................................................................................................. 64 3.13 Operation & Maintenance ............................................................................................ 65 3.14 Multi-Vendor Support ................................................................................................... 71 3.15 Wholesale/Retail Management .................................................................................... 72 3.16 Security Aspects .......................................................................................................... 76 3.17 Redundancy................................................................................................................. 77

4 Solutions ....................................................................................................... 79 4.1 Overview ...................................................................................................................... 79 4.2 IPSE in Broadband DSL Networks .............................................................................. 80 4.3 IPSE in Multi-Service Reference Architecture ............................................................. 81 4.4 IPSE in eTOM Business Process Framework ............................................................. 82 4.5 Predefined Solutions.................................................................................................... 83


4 221 02-FGC 101 302 Uen C 2006-03-14

5 Architecture................................................................................................... 85

6 Standards and Interfaces............................................................................. 87

7 Deployment ................................................................................................... 89

8 Benefits.......................................................................................................... 91

9 Summary ....................................................................................................... 93

10 Appendix ....................................................................................................... 95 10.1 Juniper ERX Resource Adapter................................................................................... 95 10.2 Cisco Resource Adapter .............................................................................................. 96

11 Terms and Acronyms................................................................................... 99

12 References .................................................................................................. 103

Table of Figures Figure 1 Policy-Based Infrastructure ..........................................................................10 Figure 2 IPSE Policy-Based Framework ....................................................................16 Figure 3 Service Portal Interoperability with IPSE......................................................22 Figure 4 Customer Care System Interoperability with IPSE.......................................23 Figure 5 Service Fulfillment Interoperability with IPSE...............................................24 Figure 6 Tiered Bandwidth Service Activation Sequence Diagram. ...........................31 Figure 7 Turbo Button Service Activation Sequence Diagram ...................................33 Figure 8 Business VoIP Sequence Diagram ..............................................................35 Figure 9 Create Subscriber Use Case........................................................................40 Figure 10 Unauthenticated User Login through Service Portal ..................................50 Figure 11 User Authentication....................................................................................52 Figure 12 Dynamic Service Activation and Deactivation ............................................55 Figure 13 Service Fulfillment Workflow Process ........................................................56 Figure 14 Policy Management Tool (PMT).................................................................63 Figure 15 IPSE in Intelligent Service Edge Network ..................................................80 Figure 16 IPSE in eTOM Business Process Framework............................................82 Figure 17 IPSE 2.0 Main Architectural Components ..................................................85 Figure 18 IPSE 2.0 Standards and Interfaces............................................................87


221 02-FGC 101 302 Uen C 2006-03-14 5

1 Introduction

1.1 Purpose The purpose of this document is to present a technical overview of the Ericsson IP Service Engine (IPSE), Release 2.0.

1.2 Scope This document examines the core functionalities, integration scenarios in existing network and OSS infrastructures, and the solutions offered by IPSE.

1.3 Audience This document is intended for system integrators and technical specialists.

1.4 How This Document is Organized The IPSE 2.0 Technical Product Description is organized into the following sections:

Section Description

Introduction This section describes the purpose, scope and audience for this document, and the contents, conventions, and related documents.

Background This section describes IPSE 2.0 in the context of the current IP services market, provides general information on policies and services, and looks at IPSE’s place in the market.

IPSE Functionality This section examines the end-to-end operations of IPSE and describes the various functions such as the Service Portal, Order Management Interactions, BRAS functions, Service Fulfillment Management, Service Management, Policy Management, Session Management, OA&M, Security, and Redundancy


6 221 02-FGC 101 302 Uen C 2006-03-14

IPSE 2.0 Solutions This section describes the intended objectives for IPSE, and the core features and enablers currently offered.

Architecture This section examines the components that comprise the IPSE system including the Web Service Layer, Web Application Server, Business-oriented Systems, Service Logic Controller, Policies, Policy Repository, OAM GUI, LDAP Server, Resource Adaptors, and so on.

Benefits This section describes the key benefits of IPSE 2.0.

Summary This section provides a summary of this document and IPSE 2.0.

1.5 Conventions Used in This Document The following typographic conventions may be used in this guide:

Font Description

Courier Commands

Directories

Bold Fields

Menu options

Dialog boxes

Windows

Italics User-supplied information

File names

Variables

References to manuals or sections in a document


221 02-FGC 101 302 Uen C 2006-03-14 7

1.6 Related Documents Additional IPSE 2.0 documents are as follows:

• IPSE 2.0 Feature Description, 1/1221 04-FGC 101 302

• IPSE 2.0 System Impact Document, 4/174 02-FGC 101 302

• IPSE 2.0 System Requirement Document, 1/1056-FGC 101 302

• EMM Provisioning Solution Description, 2/1555-APR 901 460/3

• IPSE 2.0 Dimensioning Guidelines, 2/192 02-FGC 101 302

• RADIUS Compliance Specification IPSE 2.0, 1/174 02-FGC 101 302

• PCIM Compliance Specification IPSE 2.0, 2/174 02-FGC 101 302

• SNMP Compliance Specification IPSE 2.0, 3/174 02-FGC 101 302

• LDAPv3 Compliance Specification IPSE 2.0, 4/174 02-FGC 101 302


8 221 02-FGC 101 302 Uen C 2006-03-14


221 02-FGC 101 302 Uen C 2006-03-14 9

2 Background

2.1 Current Market The lack of IP services diversity and packaging options flexibility in the broadband Internet access industry has led to a situation where operators need new ways of generating revenues. High churn rate and unparalleled competition have forced broadband access operators to aggressively look for alternatives to their current monthly flat fee business model.

Operators need to have the capability to deliver new services quickly and at a low price. These services, in some cases, are transient and require immediate attention and intervention in order to capture quick market opportunities. With today’s typical service delivery environment (or absence of), it is extremely difficult to capture these promising market opportunities, as it takes too long to create and deliver new services.

Another important aspect is the so-called “integration tax” operators are facing when trying to integrate solutions into their existing infrastructures. OSS integration is particularly labor-intensive and consequently expensive.

2.2 IPSE Perspective IPSE is a service management solution supporting IP services in a wireline network. It manages access and IP networks to define, publish and control the delivery of IP services, while applying the latest standards of policy management to deliver services for enterprises and residential customers.

IPSE has been designed to help address current service management issues related to TTM, OPEX, CAPEX, and multi-vendor opportunities. It answers the need for an IP service delivery platform that allows the fast deployment and life cycle management of new revenue-generating IP services. It is a key component in the Ericsson Intelligent Edge products portfolio that form part of the broadband access Packet Backbone Network (PBN) for fixed and IP Multimedia systems.

The role of IPSE lies mainly in the following two areas:

• IP Services delivery and life cycle management (service definition, publication, subscription, and registration)

Note: For detailed information on workflow provisioning, refer to Section 3.9.

• Dynamic control of session-based services

Note: For detailed information on dynamic control of session-based services, refer to Section 3.2.


10 221 02-FGC 101 302 Uen C 2006-03-14

These two core enabler functionalities offered by IPSE provide a delivery platform that allows for the rapid development and introduction of IP services.

It is possible for operators to take advantage of IPSE’s constantly expanding library of template IP Services solutions. These “pre-baked” services offer service operators the means to rapidly deliver services to end-users featuring an unparalleled quality of experience. Aligned with emerging standards (eTOM, NGOSS, DSL Forum), these template solutions allow for a tight integration with an operator’s business processes.

2.3 Concepts

2.3.1 Policy-based Framework

The IPSE policy-based framework uses the policy-based infrastructure defined by Distributed Management Task Force (DMTF) and Internet Engineering Task Force (IETF) in RFC2753 as a foundation - “A Framework for Policy-based Admission Control” (See Ref 3). The standard elements found in a policy-based infrastructure are:

• Policy Console

• Policy Repository

• Policy Decision Point (PDP)

• Policy Enforcement Point (PEP)

PolicyRepository

Policy Enforcement Point

Policy Console

Policy Decision Point

Figure 1 Policy-Based Infrastructure


221 02-FGC 101 302 Uen C 2006-03-14 11

The Policy Console is the interface between the network administrator and the system. It is primarily used to create, enter, and edit policies and monitor the status of the system. It also simplifies the management process by allowing network administrators to check and validate the rules, and making sure these rules do not conflict when they are combined to make a policy. It also translates the rules to match predefined LDAP schemas in the policy repository.

The Policy Repository is typically a directory service that stores the policies and the rules generated in the policy console.

It is possible to use the same directory server as the Policy Repository to hold extended network information, such as user profiles and IP infrastructure data, giving network administrators the ability to aggregate policies that encompass large groups of objects (such as resources) or specific groups of objects.

The Policy Decision Point (PDP), also referred to as policy consumer, is responsible for accessing the policy schemas stored in the policy repository, making decisions based on policy information, and sending them to the Policy Enforcement Points. The PDP can also detect policy changes, and it conflicts and acts accordingly to correct any problems. Finally, the PDP logs events from network devices and monitors network usage.

Policy Enforcement Points (PEPs) are the actual network resources or devices that implement and enforce the policies. Policy enforcement involves the PEP applying actions according to the PDP decision and based on current network conditions. PEPs may include devices such as servers, routers and firewalls. The PEP gathers the policy information from the PDP upon start-up and stores this information in its cache. The PEP may also relay information to the PDP to keep the PDP informed of changes in the network or device conditions.

As defined by IETF, a policy-based infrastructure is designed for working in two different modes for policy management: outsourcing and provisioning model.

In the outsourcing model, the PEP receives a signaled event that must be resolved based on policy criteria that is known as policy admission control, so that when the PEP is required to make a decision through this model and cannot treat this event according to the installed configuration data, it outsources the decision-making to an external Policy Decision Point (PDP). The PDP will reply to the PEP sending the appropriate data that will be installed by the PEP and will treat the event.

This mode is also known as the “pull model”, since the PEP pulls configuration data from the PDP, or the reactive model, because the PDP reacts to the PEP requests.

In the provisioning model, the PDP pushes configuration information in the PEP. This occurs when the PEP connects to the PDP. The policies are stored in the PEP and all incoming events are served according to them. This is also known as the “push model”, since the PDP pushes the information to the PEP.


12 221 02-FGC 101 302 Uen C 2006-03-14

2.3.2 Policy-Based Network Management

The IPSE follows a policy-based framework designed from a higher level of abstraction over the traditional management techniques. The intent is that the service developers create policies that determine the desired goals of the networks rather than specific procedures. These policies are provisioned, processed, controlled, and managed by the IPSE policy-based framework, which, binds them with the current network state, transforms them into dynamic configuration data, and sends them to network devices such as an edge router, determining their behavior.

The IPSE policy-based framework allows, in addition, access and service providers to use these policies to define specific services that end-customers can subscribe to. The services may be then offered under different business models and network architectures.

Policy-based network management has arisen as a pledge technology for managing networks, distributed systems and enterprise-wide applications. It is based on high-level policies that define the desired behavior of the network. These policies define what the network is supposed to do, rather than how it is going to do it. It is largely influenced by standards organizations such as the Internet Engineering Task Force (IETF) and the Distributed Management Task Force (DMTF).

As such, it is possible to eliminate, at the design phase, some of the details that will be present in the end configuration parameters; for example, the exact bindings to user information such as an Internet Protocol (IP) address, application port number, ingress interface, and so on.

Policies are high-level rules that determine the behavior of the resources, and the network as a consequence.

This higher level of abstraction simplifies the management of large-scale networks and enterprise-wide applications, and the automation ensures that the consistency and integrity in the resources behavior across the network. The dynamic binding of policies at the IPSE policy-based framework allows network types of policies to be introduced more easily. A policy can be changed dynamically, thus changing the behavior of the managed resource without modifying the implementation or interrupting the resource's operation.

The key benefits from using a policy-based approach in the IPSE are:

• Improved Flexibility Flexibility is obtained by separating the services and policies from the actual implementation of the managed resources. Different types of services are also supported.

• Improved Scalability Scalability is improved by uniformly applying the same service and policy to large sets of resources.


221 02-FGC 101 302 Uen C 2006-03-14 13

The IPSE policy-based framework is flexible in that it provides the necessary abstractions to manage a variety of resources, with different capabilities and limitations, from different vendors. It also defines how the network's resources are to be allocated among its clients. Clients can be individual users, departments, host computers, or applications.

2.3.3 Policy Core Information Model

The key building block of the IPSE policy-based framework is the policy component.

2.3.3.1 Policies as Business Entities

Policies represent business goals and objectives. A translation must be made between these goals and objectives and their realization in the network. The high-level descriptions must be translated into lower-level, but also vendor and device independent specifications.

2.3.3.2 Policy Essentials

A policy is a set of rules that guides and determines how to manage, allocate, and control network resources. Enforcement of policy ensures that rules are always followed.

A policy rule is made up of a condition that leads to an action. A condition is a set of expressions or objects used to determine whether a given action should be performed. A condition answers the question of when and where we enforce a policy. An action is a definition of what must be executed in order to enact a policy rule. An action answers the question of what must be done to enforce a policy. Together, the condition and action pair results in a specific policy rule. Policy rules may be aggregated into policy groups. These groups may be nested, to represent a hierarchy of policies.

Policies can either be used in a stand-alone fashion or aggregated into policy groups to perform more elaborate functions. Stand-alone policies are called policy rules and can be expressed in a simple statement. Policy groups are aggregations of policy rules, or aggregations of policy groups, but not both.

The semantics of a policy rule are that if the set of conditions evaluates to true, then the set of actions that either maintain the current state of the object or transition the object to a new state may be executed. For the set of actions associated with a policy rule, it is possible to specify an order of execution, as well as an indication of whether the order is required or merely recommended. It is also possible to indicate that the order in which the actions are executed does not matter. Policy conditions and actions have two principal components, operands and operators. Operands can be constants or variables. A policy cannot be constructed without specifying the operands to be examined, the operands to be changed, and


14 221 02-FGC 101 302 Uen C 2006-03-14

how they should be bound together. Policy rules themselves can be prioritized.

2.3.3.3 Extensible Policy Core Information Model

The IPSE policy-based framework uses as a base the IETF Policy Core Information Model (PCIM) for representing policies. PCIM, as defined in the IETF RFC 3060, provides a simple object-oriented information model for representing policy information such as policy conditions, policy actions, policy groups, and policy rules.

PCIM model defines two types of object classes:

• Structural classes for representing policy information.

• Association classes that indicate how instances of the structural classes are related to each other.

The policy specification has been designed to assist human administrators in their definition of policies to control a networking environment. The PCIM specification has been developed to be independent of any particular data storage mechanism and access protocol.

The PCIM classes are intended to serve as the foundation for the lower level, vendor and device independent specifications. The classes are intended to serve as an extensible class hierarchy through specialization, defining policy objects that enable application developers, network administrators, and policy administrators to represent policies of different types.

Specifically, PCIM defines the generic structure of a policy, and provides a framework for describing the specific conditions and actions that are used to construct application and domain-specific policies. Furthermore, a draft is under development at IETF defining the mapping of these information model classes to a directory that uses LDAP as its access protocol.

For the structural classes in the information model, the mapping is basically one-for-one: information model classes map to LDAP classes, information model properties map to LDAP attributes.

For the relationship classes in the information model, different mappings are possible. In this document, the PCIM relationship classes and their properties are mapped in three ways: to LDAP auxiliary classes, to attributes representing Distinguished Name (DN) references, and to superior-subordinate relationships in the Directory Information Tree (DIT).

The PCIM Extensions (PCIMe), presently under development, as well as at IETF, define new policy classes such as simple policy condition, compound policy conditions (conditions with sub-conditions), simple policy actions compound policy actions (actions with sub-tasks) and nested rules. PCIMe also introduces the concept of policy variables and policy values.

The policy classes and associations defined in this model are sufficiently generic to allow them to represent policies related to about anything.


221 02-FGC 101 302 Uen C 2006-03-14 15

However, in the IETF, it is expected that their initial application will be for representing policies related to Internet QoS and Differentiated Services (DiffServ).

Policy groups and rules can be classified by their purpose and intent into seven different kinds of policies: Motivational Policies, Configuration Policies, Installation Policies, Error and Event Policies, Usage Policies, Security Policies, and Service Policies. This classification is useful in querying or grouping policy rules. It indicates whether the policy is used to motivate, when or how an action occurs, or to characterize services that can then be used, for example, to bind clients to network services. These categories are represented in the PCIM by special values defined for the PolicyKeywords property of the abstract class Policy.

2.4 IPSE 2.0 Policy-Based Framework The purpose of the IPSE policy-based framework is to manage and control network resources, so that network operations conform to the business goals of the organization that operates the network. Ultimately, achieving such control requires altering the behavior of the individual entities that comprise the network.

Instead of configuring each of the network resources or devices through network management applications individually, the framework provides an alternative approach to controlling the operational characteristics of an entire network. This means a shift of the focus on configuring individual devices to setting policy for the network in aggregate, and controlling resource behavior through specific policies.

The following figure shows the overall architecture of the IPSE policy-based framework.

As shown in Figure 2, the main components of the IPSE adhering to its policy-based framework are:

• Service Logic Controller

Composed of:

o Web Service Interface

o Service Management

o Policy Management Components

o Resource Adapters

• Policy Management Tool

The Policy Management Tool has its own web interfaces.

• Policy Repository (LDAP based)


16 221 02-FGC 101 302 Uen C 2006-03-14

PMT

Policy Repository

SLC

COPS,RADIUS,Others

Policy ManagementComponent

Service/User/ResourceProfile Management

Services Interface

Resource Adaptors

Policy Interface

XML/HTTP

Web Services

Figure 2 IPSE Policy-Based Framework

The Service Logic Controller performs the evaluation of enabled policies based on incoming requests via the following interfaces:

• Access Layer Interfaces

The IPSE 2.0 includes Web Service interfaces

• Resource Adaptor Interfaces

The IPSE 2.0 includes RA interfaces for Juniper ERX-series (models 310, 700, 1400) routers

Note: As IPSE is a multi-vendor platform, it is possible to support RAs for other vendors.

The Service Logic Controller makes decisions selecting policies that are subsequently downloaded to the RAs. The Service Logic Controller uses the domains to find the resources or devices to which the actions are to be applied. The Service Logic Controller provides the ability to perform translation of vendor and device independent policies in a networking environment that has different devices (servers, routers, and so on) with


221 02-FGC 101 302 Uen C 2006-03-14 17

different capabilities. In the architecture, the Resource Adapters, parts of the Service Logic Controller, perform this translation. As shown above, the interface to the network resources or devices can involve various protocols such as Command Line Interface (CLI), SNMP, COPS and so on.

The Policy Management Tool provides the ability to create, modify, delete, enable and disable policies. It stores the policy information in the Policy Repository.

The Policy Repository is constructed as a directory hierarchy. Both the Service Logic Controller and the Policy Management Tool use the LDAP protocol to access the directory of the Policy Repository.

The main components of the architecture are described in detail in subsequent sections of this document.


18 221 02-FGC 101 302 Uen C 2006-03-14


221 02-FGC 101 302 Uen C 2006-03-14 19

3 IPSE Functionality The functionality of the Ericsson IP Service Engine 2.0 is principally governed by the requirements of broadband remote access service - network edge management using a policy-based framework. IPSE complies with the IETF recommendations for a policy framework. The policy-based framework of IPSE allows access and service providers to enable differentiated, added value IP services such as bandwidth-on-demand, video-on-demand (video clips), stateless firewalls, and so on, by using different policies and grouping them together. Instead of configuring each of the network resources or devices through network and element management applications individually, the IPSE framework provides an alternative approach to controlling the operational characteristics of an entire network.

Corresponding to different services offered by the network service provider, policies are provisioned, processed, controlled and managed by the IPSE policy-based framework. These policies are transformed into dynamic configuration data and sent to network devices such as edge routers. These predefined policies define the network behavior for specific sessions and ensure that the necessary network resources are properly provisioned to fulfil the needs of the services delivered over a broadband, IP network. IPSE carries out the corresponding policy provisioning on the network resources through a set of plug-in modules called Resource Adaptors (RAs).

The service fulfilment functionality in IPSE enables predefined services to be handled by the system from the point of service publication without any manual interaction from the operator. The end-users can do all of the necessary self-administration using self-subscription portal technology needed to have a new service delivered. Such activities include subscription and service initiation, but also modification of service parameters (where allowed in the service) to tailor the service to the user’s preferences. The automated processes also communicate with external systems when required to deliver a complete service. IPSE offers a library of IP service provisioning definitions. In general, these pre-defined services require a certain amount of customization to integrate with the customer’s infrastructure and business processes.

IPSE offers a standard interface for easy integration to the surrounding business, operational, and network management systems to create a complete and comprehensive service management solution. The solution is designed to simplify the integration with both internal and external systems:

The descriptions presented in this section examine the functions and features of the Ericsson IPSE.


20 221 02-FGC 101 302 Uen C 2006-03-14

3.1 End-to-End Operations IPSE enables policy-based network management and enhances the rapid deployment of enhanced IP services, by providing “end-to-end operations”.

End-to-end operations occur in a bi-directional flow-through of service and policy provisioning data between the network resources such as routers, and the end-users and the provider's back-office systems.

The operations occur between two layers:

• Business process oriented top layer

• Network-oriented bottom layer with specific resource interfaces

At their highest level of abstraction, policies represent business needs. Their presence and enforcement directly affect the goals and objectives of the business functions. Bridging the gap between the business contexts that are often managed by sophisticated systems (beyond the business process-oriented top layer of the IPSE), and the management of network resources, requires flexible communication between the layers. The interactions between the layers are seldom strictly top-down or bottom-up. Since policies can merge conditions coming from different layers (within and outside of the IPSE), end-to-end operations may occur freely, as the policies are applied.

3.1.1 Business Operations

Business operations cover a broad scope of functionality. From service definition to billing strategies, much is included in the external business-oriented processes that can interact with the IPSE.

The IPSE, while playing an integral role in business operations, is itself unaware of them. The functionality offered by the IPSE reflects the capabilities related to policy and service management in the varying context of business operations. They enable interoperability with the broadest number of external processes. Generic interoperability is a design goal. To attain it, the core policy rule engine within the IPSE is void of any business context awareness.

The protocols and interfaces introduced by the IPSE to link with business domains are generic enough to be easily extensible to different needs.

In the IPSE 2.0, an Application Programming Interface (API) with the Simple Object Access Protocol (SOAP), that uses the Extensible Markup Language (XML), has been specifically developed to explore BRAS management functions. They include the following:

• Login an authenticated user who already has an open session

• Logout a user with an open session (requesting the network element) to close it.

• Get the list of activated services


221 02-FGC 101 302 Uen C 2006-03-14 21

• Verify the authentication status locally cached in the session data of a particular end-user

• Activate a service for a particular end-user

• Deactivate a service for a particular end-user

Because XML is extensible, it is able to describe the data that is transmitted. The end-points receiving or sending such format can be dissociated from their actual semantic.

The IPSE does not need to understand fully all of the information that is exchanged between the external business-oriented processes. The semantic of the interchanged data should be handled by the policy conditions and actions that have been stored in the Policy Repository.

The traffic logic responsible for decoding and encoding the values, as well as making the correspondence between policy conditions and actions, is feature-based and interchangeable. The BRAS-specific interfaces and functions that are available in the IPSE 2.0 represent only a sample of such traffic handling.

Overall, the business operations are created from the correlation of business logic external to the IPSE, and policies that are stored in the IPSE. Some plug-in adapters may be required in the IPSE. They are not tightly coupled with the core functions of the IPSE.

The IPSE uses RADIUS, LDAPv3, and SNMPv3. They are standard protocols, but flexible enough to be adapted to several business environments with respective vendor-specific attribute dictionaries, directory schemas, and managed information bases.

• RADIUS is used to send out the accounting information demanded by billing-related business operations.

• LDAPv3 is used by the IPSE to retrieve policy information, user profiles, service data, and associations between services and policies. The latter information can be provided externally from the IPSE.

• SNMPv3 provides a more detailed view of the internal statuses within the IPSE, as sessions are managed, services are activated, and policies are enforced.


22 221 02-FGC 101 302 Uen C 2006-03-14

In the IPSE 2.0, three major types of business-process oriented systems are considered:

• Service Portals

• Customer Care Systems

• Service Fulfilment Engines

All are capable of requesting policy provisioning to be carried out. These systems connect to the IPSE through a set of web services, illustrated as the northbound interface in the following illustrations, and allow for the external systems to query the IPSE for information, as well as request policy provisioning to be carried out.

3.1.1.1 Service Portal Interoperability

Access Network

Service Portal

BroadbandService

BroadbandService

BroadbandService

BroadbandService

IPSE

NetworkDevice

Remote IP Connection

Network Access Notificationsand

Policy Provisioning

Use

r Log

inSe

rvic

e Ac

tivat

ion

Man

agem

ent

HTTP redirection

RADIUSServer

RADIUS Accounting

RADIUSAuthentication

User DatabasesLDAP

Figure 3 Service Portal Interoperability with IPSE

A Service Portal presents available services to end-users and allows them to select services to be activated. The information is normally retrieved from a Lightweight Directory Access Protocol (LDAP)-based directory. When the user selects a service, the Service Portal sends a request to the IPSE to carry out provisioning on the network elements. If the service is billed on usage, the Service Logic Controller can also communicate with a RADIUS server as necessary.


221 02-FGC 101 302 Uen C 2006-03-14 23

3.1.1.2 Customer Care System Interoperability

End-users

Customer CareSystem

Access Network

IPSE

NetworkDevice

Remote IP Connections


Policy Provisioning

Use

r Log

inS

ervi

ce A

ctiv

atio

nM

anag

emen

t

User Databases

RADIUSServer

RADIUS Accounting


LDAP

Figure 4 Customer Care System Interoperability with IPSE

An operator with a back-office system such as a Customer Care System (CCS) can integrate with the IPSE using the offered web services. The CCS connects directly to an external storage of customer and policy data. The CCS handles complete user and service provisioning cycles with service fulfillments for events like service subscription and registration and user management. The CCS can have its own Service Portal solution allowing for self-provisioning. The CCS calls the Service Logic Controller when provisioning on a network resource is needed.


24 221 02-FGC 101 302 Uen C 2006-03-14

3.1.1.3 Service Fulfillment Engine Interoperability

Internet ServiceProviderInternet Service

Provider

Access Network

IPSE

NetworkDevices

Remote IP Connections


Policy ProvisioningU

ser L

ogin

Ser

vice

Act

ivat

ion

Man

agem

ent

User Databases

RADIUSProxyServer

RADIUS Accounting


LDAP

Internet ServiceProviderInternet Service

Providers

LDAPEnd-users

RADIUSServer

BroadbandService

BroadbandService

BroadbandService

BroadbandService

Service FulfillmentEngine

Figure 5 Service Fulfillment Interoperability with IPSE

If the capabilities of a pure Service Portal solution are not enough or the operator does not have a CCS with service fulfillment functionality, it is possible to use the IPSE Service Fulfillment Engine. Again, for the communication with the Service Logic Controller, the SOAP/XML over HTTP interface is used for integrating the IPSE with the Service Fulfilment Engine (SFE). The SFE comes with a Service Portal solution, service creation capabilities and databases, or it can reuse existing functionality and integrate it with legacy CSS.


221 02-FGC 101 302 Uen C 2006-03-14 25

3.1.1.4 User Databases Interoperability

User databases are not business-oriented processes. They store information about users and their subscribed services that is important to the business processes.

The IPSE architecture has an open-ended design to interface with user databases. Using a plug-in approach to integrate specialized adapters to user databases, the IPSE can handle a multitude of database schemas, either complex or straightforward, to represent user profiles and service capabilities.

The IPSE can retrieve any information from an external database through its pluggable adapters and customizable search criteria. Therefore, validated users, their subscribed services, and associated policies can be determined at run-time by the IPSE, through (LDAP, SQL, simple flat file, and so on) lookup searches.

In the IPSE 2.0, examples of User Manager plug-in components are the IPSE Default User Database plug-in and the Service Fulfilment Engine LDAP plug-in. The latter uses the LDAP protocol, but there is also the possibility to query a relational database with SQL.

A Java-based Application Programming Interface (API) exists to create new User Manager Plug-in components that can be deployed within the IPSE Service Logic Controller.

3.1.2 Network Operations

The IPSE acts upon service provisioning requests (business operations) handled through a set of Web Services that are accessed through Simple Object Access Protocol (SOAP), which is based on the Extensible Markup Language (XML), over the Hypertext Transfer Protocol (HTTP).

From this point, the IPSE takes control over the actual management of the provisioned policies and their enforcement. Policies are enforced through the timely execution of configuration modifications done to the managed network elements. Thus, automation is obtained, providing an “intelligent” network that is able to cater to the needs of high-level business services.

3.1.2.1 Centralized Policy Management

The IPSE holds the central role of holding all policy rule definitions in a repository whose data is persistent. Many Service Logic Controllers can share the same repository for policy information. The stored policy data is safeguarded from any loss due to the disruption or unavailability of the Service Logic Controllers.

An LDAP directory is used for the policy repository. The LDAP server used to hold the Policy Repository is expected to run externally to the


26 221 02-FGC 101 302 Uen C 2006-03-14

IPSE. It is assumed that it may also serve other directory services specific to the deployment environment.

A policy manager component is responsible for fetching the stored policy rules. Rules can be obtained individually or grouped in a hierarchical structure.

For time-based policy rules, a policy rule engine takes care of recognizing them and coordinates with a time-scheduler to plan eventual conditions at which specified actions will be triggered.

3.1.2.2 Loosely-Coupled Network Resource Management

The IPSE carries out the corresponding policy provisioning operations on the network resources through a set of pluggable modules called Resource Adapters (RAs).

Each RA handles a specific type of resources and uses resource-specific high and low-level protocols to communicate with the managed resource.

This approach makes the policy processing in the Service Logic Controller “agnostic” to the specifics of the network elements.

The Service Logic Controller also acts upon resource-triggered events for configuration information and policy decision requests received from the network resources through the RAs.

3.1.2.3 Localized (Domain-Specific) Session Management

The IPSE handles the session management for policy rules whose enforcement requires the storage of dynamic state information (IP-Address, user login name, authentication state, and so on.)

The IPSE can either hold full control over the life cycle of the sessions or be a synchronized slave to an external process managing master sessions.

Session management for multiple distinguished domains is supported by the IPSE.

The IPSE incorporates a dedicated database that allows various monitoring queries on the stored session information. When many IPSEs are running in a cluster, they all access a shared session database.


221 02-FGC 101 302 Uen C 2006-03-14 27

3.1.2.4 Dynamic Authentication Verification and Accounting Reporting

For authentication and accounting of end-users of IP services, the IPSE relies on one or more RADIUS servers. The RADIUS server can be co-located with the IPSE or remotely connected.

Relying on an external RADIUS server is one of the key elements in supporting the wholesale model. In this case, the access provider owns the IPSE, while the service provider owns the RADIUS server and its customer data.

Accounting is started upon the enforcement of policies that correspond with the creation of a state-full session (for example, IP connection login). It is stopped when the session is terminated by timely events (for example, user IP connection logout, administrator intervention).

Interim Accounting updates may originate directly from the network elements.

All accounting records are normally forwarded to the RADIUS server. Upon a failure of the RADIUS Server, the IPSE can store a limited backlog amount of accounting records for safe keeping during the inadequacy period. Service-specific accounting updates are supported in the IPSE 2.0.

Accounting information that is relayed to the RADIUS server contain at the minimum the following data:

• User Identification

• Domain Name

• Service Identification (unique)

• Service Name

• Policy Group Name

• IP Address

• Start time

• Duration


28 221 02-FGC 101 302 Uen C 2006-03-14

3.1.2.5 Ericsson Ethernet DSLAM (EDA) Access Network Interoperability

The IPSE incorporates the following functionality for enhanced interoperability with the Ericsson Ethernet DSLAM Access (EDA) network.

1. Automatic login with memorized access network-specific identifiers:

• This feature allows automatic registrations of persistent subscribers that are connected through the Ericsson EDA access network to an IPSE-controlled BRAS node (edge routers). Persistent subscribers do not need to be explicitly authenticated by entering user name and password.

• The IPSE holds BRAS/edge router control functions that are key for an enhanced integration with the Ericsson Ethernet DSLAM Access (EDA) network. The IPSE is capable of automatically binding Virtual MAC (VMAC) addresses or DHCP Option 82 identifiers with an end-user’s session.

• The EDA access network provides the VMAC and DHCP Option 82 identifiers. After a valid authentication of the end-user, the VMAC or DHCP Option 82 can be memorized by the IPSE, and used as token- credentials for future login and session establishments in the edge routers.

• The registration process of the end-users for his/her corresponding VMAC or DHCP option 82 in the EDA access network is transparent and automated.

2. Compatibility with Service per Virtual LAN (VLAN) feature in the access network:

• The IPSE removes any constraint in the BRAS/edge routers that can restrict a connected EDA access network to provide segregation and assurance of bandwidth by assigning “Service per VLAN”.

The IPSE is able to instruct the edge router to dynamically allocate IP sub-interfaces on a specific VLAN.

3.1.2.6 Single Sign-On

As part of Ericsson's wider initiative Service Network Framework (SNF), the IPSE supports a Single Sign-On (SSO) service. Single Sign-On enables subscribers to authenticate themselves only once per session, when interacting with both network devices and business processes that are bound to IPSE. For example, a subscriber does not have to log-in again into the Service Portal if the Service Logic Controller already has knowledge of the user session and it is authenticated. The enabling of this function is configurable. At the creation of each domain, IPSE shall be able tocan disable single sign-on function.


221 02-FGC 101 302 Uen C 2006-03-14 29

3.2 Scenario 1: Dynamic Control of IP Services The policy-based framework of the Ericsson IP Service Engine is primarily used in the context of broadband remote access services to the Internet.

A desired goal in facilitating the management of broadband router access through policy control is to enhance the service experience of the end-users. Thus, it is a step away from the basic best-effort means of obtaining and sending IP packets of data. The solution strives to cater to more evolved needs such as guaranteed bandwidth allocations that are dynamic, on-demand, and per-individual service specific.

To better serve applications such as streaming, rich-media content, conferencing, or conversational sessions, a seemingly more complex control of the routing network devices residing at the edge of the access network is demanded. However, this new control complexity does not have to be passed-on to the end-users, network operators or service providers. It is, therefore, evident that the policy-based framework offered by Ericsson’s IPSE is necessary to manage the more demanding requirements of dynamically controlled services, and remove the intrinsic details of network configuration. By relying on IPSE, its users can reap the benefits of an automated and seamless control of the access network.

Dynamically controlled services are, in general, transient and exist for the duration of the service session. They do not affect the subscriber subscription to the service. An example of such a service is a gaming button (for example, turbo button) where the available bandwidth is increased for the duration of the session. In this case, the subscription remains unchanged, so that when the users logs in again, the bandwidth is returned to its original, registered subscription level.

This section presents the dynamically controlled IP Service solutions currently offered by IPSE 2.0.

• Tiered Bandwidth

• Turbo Button (also known as Gaming Button)

These two services present some similarities with respect to their ability to offer subscribers with self-management of network bandwidth. They differ, however, in that Tiered Bandwidth offers bandwidth tiers for the duration of an active session, whereas the Turbo Button offers the maximum bandwidth available for a specific amount of time.


30 221 02-FGC 101 302 Uen C 2006-03-14

3.2.1 Tiered Bandwidth

3.2.1.1 Technical Description

The tiered bandwidth service allows a subscriber to modify the amount of available bandwidth to which he is entitled for the duration of the on-going session. It is important to note that the modification takes effect immediately (in real-time).

The subscriber can choose among three bandwidth tiers. For example:

• Gold

• Silver

• Bronze

Each bandwidth tier has an associated cost to it. After the subscriber has made a choice, the selected bandwidth is available for the duration of the PPP session.

3.2.1.2 Service Model

The currently implemented tiered bandwidth solution is modeled on a dynamically activated service paradigm, as it does not modify the existing subscription level. The typical scenario presented herein is based on a three-bandwidth tiers model – Gold, Silver and Bronze. It is possible to dynamically switch the level of available bandwidth by selecting one of the three tiers.

Three mutually exclusive (radio button) services are created in the SLC to support this scenario. Only one tier can be selected at a given time. A subscriber from the self-service portal can activate these services dynamically in real-time.

3.2.1.3 Application Flows

Figure 6 is a sequence diagram depicting the different flows involved in the modification of a bandwidth tier. The diagram assumes that an authorized session is already created and active.


221 02-FGC 101 302 Uen C 2006-03-14 31

Subscriber Self-Service Portal

SLC BRAS RADIUS Accounting

Resource Adapter

Activate BW Tier

Act ivate B W Tier

Send Policy

Modi fy P olicy

Confi rm Pol icy Change

Confirm Change

Find Policy

Service Accounting

Confirm New BW Tier

Send Confirmation Page

Figure 6 Tiered Bandwidth Service Activation Sequence Diagram.

3.2.2 Turbo Button

In certain situations, subscribers may be interested in using a service that would provide a higher access speed at the times they need it most. For example, higher access speeds can be applied to content downloads such as large MS Office service packs or movie trailers, and online gaming. This is often called a “Turbo Button” service. The higher access speed limit provides a higher speed tier or potentially eliminates or lessens artificially imposed limits on the achievable speed altogether. This is applied to the end user’s PPP session – so it will affect all the applications


32 221 02-FGC 101 302 Uen C 2006-03-14

and activities that make use of that connection. The Turbo Button service can also be invoked for the community ISP, so that all users attached to the home network of the customer receive the advantage of Turbo Button service. This can be applied to Internet gaming or LAN parties where a group of subscribers is affected.

3.2.2.1 Service Model

Many implementations of a Turbo Button service are possible. For the purposes of this use case, a simple implementation is presented in which a Network Service Provider called BigPipe.com offers the service. BigPipe uses IPSE’s Self Service Portal (SSP) to offer services to their subscribers. A subscriber requests the Turbo Button service at BigPipe’s SSP web site during a browsing session at normal speed.

Once the subscriber requests the turbo button service, IPSE determines, via the subscriber profile in LDAP, what options can be presented. Through the SSP, BigPipe can map the available upgrades to marketing categories (for example, fast, faster, ultra fast). The subscriber selects one of the options, and the SSP requests the profile from the Policy Server that supports the requested speed. Through the Resource Adapter (RA), the Policy Server pushes new policy (for example, classifiers, rate limiters, priority) configuration data to the router that supports the higher speed. It is important to note that the service is still “Best Effort”; there is no assumption of a QoS guarantee in this example. A version of a Turbo Button service with QoS support is, of course, possible.

The Turbo Button service can be permanent (P-TBS) or temporary (T-TBS). In P-TBS, the enhancement lasts until the user requests a return to the original access rate (and billing plan). In T-TBS, the enhancement lasts only for a certain fixed period of time, after which the default service rate is re-established.

In a typical business model, the BigPipe can bill the subscriber for usage of the Turbo Button service via Radius accounting.


221 02-FGC 101 302 Uen C 2006-03-14 33


The following sequence diagram shows an example of the events that occur while a subscriber uses the Turbo Button Service via a network service provider called BigPipe.com. The first part of the sequence diagram represents the login of the subscriber requesting a normal session. The second part describes how the subscriber activates the Gaming Button.

create session result (session -id)

RADIUS accounting start

Normal non-Turbo session establishedSubscriber A visit the "Turbo Button" web site

Validate Subscriber A's maximum bandwidth allowed

Subscriber A has the right to use "Turbo Button" ie allowed to get more bandwidth

Subscriber A receives "Turbo Button " option

Subscriber A BigPipe.com :xAuthority : Policy Server : Resource

Adapter Router : LDAP Services

Directory : Radius Node

Susbcriber A selects a "Turbo Button" option

Portal generates dynamic jsp page

HTTP response (service result)

SOAP activate TURBO

SOAP activate TURBO (result)

Update session

activate_service (TURBO)

activate_service_response (result)

Access Request (service login command, TURBO) Access Accept (result)

RADIUS Accounting Sta rt (activated service)

RADIUS accounting - start start_accounting

Session Request

access -request authenticate user

access request access accept

authenticate user result

access accept account logon

start accounting

create session

Session with Turbo activated

Figure 7 Turbo Button Service Activation Sequence Diagram


34 221 02-FGC 101 302 Uen C 2006-03-14

3.3 Scenario 2: Static Provisioning of IP Services

3.3.1 Business VoIP

VoIP is generally considered the migration of narrow band voice services into an IP network. Once voice is provided through an IP network, it can be integrated with other IP services providing capabilities that are not achievable or cost effective in the PSTN. This section illustrates how IPSE components can be applied to VoIP services.


This use case focuses on a service provider-centric (ASP) model rather than a completely decoupled peer-to-peer model. The use of SIP as the application protocol is assumed. This use case describes the underlying network capabilities that enable basic call establishment, rather than the the calling features associated with the VoIP service.

In this use case, a two-way call is established. Presumably, multi-party audio conferencing will be a feature of the VoIP service and as a result a media server (mixer) is required. Two-way calls between SIP users could be routed to the conference bridge providing a well-known IP address that can be used for classification.

For simplicity, this use case assumes that the CPE marks the traffic and is policed in the network. The CPE could be a SIP phone, Analog Terminal Adaptor (ATA), or an Integrated Access Device (IAD) that has a built-in xDSL modem.

The following diagram shows the sequence of events that would occur in the process of registering the ASP VoIP service with a specific user. It is assumed that two users A and B will be involved in a VoIP call.

1 The VoIP ASP uses the service creation capability of IPSE’s Service Fulfillment Engine to define the VoIP services and to provision subscribers with the VoIP services.

2 On the VoIP ASP website, Subscriber A registers and creates a user profile, billing options, and so on. Subscriber A can also obtain, configure, or download the VoIP client application.

3 Upon successful VoIP services subscription, the VoIP ASP then offers Subscriber A different package options (number of simultaneous lines, voice quality options per line, and so forth). Subscriber A activates VoIP services via the Self Service Portal. Subscriber A receives confirmation of the activation of his VoIP services. The setup of subscriber A’s VoIP service is completed at this point.


221 02-FGC 101 302 Uen C 2006-03-14 35

Subscriber A :

Subscriber B :

: Service : xAuthority : Policy Server

: Resource Adapter

Router : LDAP Services Directory : Radius ASP

Susbcriber A selects a VOIP services

Portal generates dynamic jsp

HTTP response (service

SOAP activate VOIP

SOAP activate VOIP (result)

activate_service (VOIP_service)

activate_service_response (result)

Access Request (service login command,

Access Accept (result)

RADIUS Accounting Start (activated service)

RADIUS accounting-start start_accounting

Subscriber A visit the VOIP services

Validate Subscriber A's profile for VOIP

Subscriber A has the right to use VOIP

Subscriber A receives VOIP services

Provision VOIP services and VOIP Define VOIP services into the Services

SIP Invite "calling Subscriber B" -

SIP Invite "call from user A".

Figure 8 Business VoIP Sequence Diagram

PP session established. For details of setting up the session refer to GAMING’s sequence diagram.

VOIP set up for Subscriber A complete.

VOIP call established


36 221 02-FGC 101 302 Uen C 2006-03-14

4 Subscriber A decides to call Subscriber B using the VoIP ASP’s service.

5 The ASP verifies that Subscribers A and B have active accounts, performs telephone number-to-IP address mapping and informs B of an inbound call.

3.3.1.2 More Advanced Capabilities

This section provides a brief overview of more sophisticated VoIP features that were not detailed in the previous use case. The following additional capabilities are provided by the IPSE solution. The key features of IPSE’s Business VoIP provisioning solution include:

• Provisioning support for an extensive set of user and group calling features for the business VoIP market.

• Flexible definition of VoIP feature bundles and the ability to readily differentiate offerings for different market segments

• Intelligent business logic that simplifies the management of business dial plans, including multi-site extension management.

• Extensive telephone number management capabilities, including support for virtual numbers, as well as number reservation, assignment and aging

• Easy-to-use, task-based portals for both service provider personnel and customer administrators and employees

• Task-based Customer Administration portal, which enables customer administrators to select calling features and manage employee and group configuration data

• Task-based employee self-service portal, which enables employees to manage their own VoIP options

• Tracking and assignment of manual tasks related to CPE ordering and shipment, emergency services (such as E911), and Local Number Portability (LNP)

• Workflow-generated e-mail notifications for coordinating manual provisioning tasks

• Flexible, standards-based integration with existing back-office systems, including billing, order management, CRM, and inventory systems


221 02-FGC 101 302 Uen C 2006-03-14 37

3.4 Engine MultiMedia (EMM) Note: For detailed information on the EMM solution, refer to the document entitled EMM Provisioning Solution Description, 2/1555-APR 901 460/3. IPSE can accommodate the needs of EMM 2.1 in providing the classical provisioning (Creating, Modifying, and Removing Subscriptions) and the self-provisioning as an integrated solution. Self-Provisioning is implemented as an integrated part of the provided service, which means it belongs to the service to which the Enterprise or Residential Subscriber has subscribed.

IPSE acts as the single point-provisioning interface for the classical provisioning used by System and Service Providers.

3.4.1 Solution

The provisioning process consist of pushing user information from a central interface to various nodes in an organized manner so each piece of information needed by the full EMM solution is available in its proper place.


38 221 02-FGC 101 302 Uen C 2006-03-14

The goal of this architecture is to provide a flexible means of provisioning various nodes from a single workflow process. The goal of provisioning from the EMM perspective is to centralize user provisioning and offer two interfaces to accomplish the task. Various design choices ensured that is a provisioning error occurs in one node, the entire process is roll backed for that particular user.

The interface is part of IPSE’s Service Fulfilment Engine where a subcomponent called the SPA (Service Provisioning Application) provides the necessary interface to provision the user information in a CSR (Customer Service Representative) role.

The Self-Admin Portal page is used to alter the service parameters and is accessible for each user. The user can alter the call forwarding number for instance or access feature information or billing summary.

3.4.1.1 Key features and enablers

• Provides an integrated provisioning solution.

• Reduces the complexity of provisioning multiple nodes.

• Introduces a flexible way to offer new VoIP services.

• Provides a user self-admin portal for service configuration.


221 02-FGC 101 302 Uen C 2006-03-14 39

3.4.2 Application Flow

1. CAS provisions IPSE with EMM data

2. .IPSE provisions the rest of EMM

3. The user accesses the portal for self-provisioning, changing data

4. IPSE passes configuration data to the EMM nodes

IPSE

CAS

HotSip HSS SRD BroadSoft IPworks

1

42

3


40 221 02-FGC 101 302 Uen C 2006-03-14

3.4.3 Use Case

The diagram below depicts the Create Subscriber scenario.

CAS EMA HSS CSS-IP DNS/ENUM HotSIP

LDAP ADD USER()

OK()

CORBA: addUser()

OK()

INSERT NAPTR()

OK()

RMI: addUser()

SRD

LDAP ADD HSS USER()

CREATE:EMMUSER()

OK()

OK()

OK()

Figure 9 Create Subscriber Use Case

* This interface requires customization at the operator’s site. The customization consists of adapting the IPSE-SFE inbound interface to the operator’s CSR application.

IPSE SFE CAS SRD HSS CSS-IP DNS/ENUM HOTSIP

OSS/J PSRI Model*


221 02-FGC 101 302 Uen C 2006-03-14 41

3.5 EDA Provisioning Solution

3.5.1 Solution

The EDA Provisioning Solution provides a flow-through, end-to-end provisioning strategy for DSL services activated through the EDA and BRAS. DSL services activation through BRAS depends upon the IPSE solution deployed. The solution provides a workflow to reserve a DSL port without the actual physical line connection and/or complete customer information, thereby allowing large-scale pre-provisioning of DSL lines. This solution reduces OPEX and time to market for operators planning large-scale EDA deployments.

The EDA provisioning and BRAS activation requirements through IPSE includes a new workflow to handle OSS/J requests to reserve EDA DSL lines, the ability to provision multiple PEMs, and the ability to provision the EDA DSLAM with multiple services. The service provisioning provided by IPSE for EDA is achieved via the PEM to provision the subscriber, establish the association between the subscriber and the EDA service, and establish the association between the line (DSL) and the subscriber. All the operations required to subscribe a customer to IPSE and EDA Internet access-based services are provided.

Orders can be accepted from an OSS/BSS/CRM via two interfaces:

1. PSRI, interface for Service Publication and Subscription, via the IPSE Service Provisioning Application

2. OSS/J, using the OSS/J Service Activation API V1.0 (Ref 8).

IPSE provides a Service Delivery Kit (SDK) to create a plug-in that enables an external NMS to retrieve resource inventory in order to locate the required PEM (to automatically provision a specific customer). In the event that no external NMS is available, IPSE provides a default resource locator.


42 221 02-FGC 101 302 Uen C 2006-03-14

3.5.1.1 Key features and enablers

• Cost Savings: New automated workflow to handle EDA line reservation.

• Operational Efficiency: IPSE centralizes the provisioning function and offers agility in the expansion of the DSL network and provisioning of new services.

• Revenue Awareness: Possibility to integrate with billing and CRM systems for the purposes of business workflow support of these functions.

• Revenue Generation: Time-to-market with new services and ability to offer chargeable differentiated services.

• Customer Orientation: A framework is available for developing a self-service portal to empower customers to modify their service offering.


221 02-FGC 101 302 Uen C 2006-03-14 43

3.5.2 Application Flow

3.5.2.1 Subscription Provisioning Using OSS/J Service Activation

When SFE receives a work order that includes customer data and configuration data for DSL with internet service, the customer creation and service subscription workflow is triggered.

There are two scenarios for service subscription: Service subscription through EDA and BRAS, or service subscription only through EDA, no BRAS involved.

First, the SFE checks to see if that customer exists. If not, the SFE adds the pertinent customer information to the user LDAP database. An end-user with administrative control over the customer account is also created. The SFE also creates EDA users through PEM if necessary.

Next, the SFE begins the process for service configuration and activation. SFE checks for resource availability (for example, the DSL line). SFE reserves resources, if necessary.

Then, SFE initiates resource provisioning and accomplishes resource activation through PEM to EDA and, if necessary, through the SLC to the BRAS.

The following sequence diagram shows the sequence of events that occur in the subscription of DSL service process.

DSL Subs cription w ith BRAS enabled s ervice

CRM SFE NMS PEM : <Proces s Nam e>

SLC

Subs cribe to DSL

As s ign DSL line

Create EDA user if needed

Set SLC policy group

Locate PEM


44 221 02-FGC 101 302 Uen C 2006-03-14

3.5.2.2 DSL Line reservation using OSS/J Service Activation

DSL lines can be reserved before a customer subscribes to high speed internet service. This can be useful when deploying lines in a new neighbourhood, pre-allocating each reserved port to a physical address or potential customer. The following sequence diagram shows the sequence of events that occur in the process of pre-reserving DSL lines.

: Network Operator SFE NMS PEM

Res erve DSL line

Create s ubscriber

As s ign DSL and Bandwith

Locate PEM


221 02-FGC 101 302 Uen C 2006-03-14 45

3.6 Web Services Layer The IP Service Engine is open to interactions from business-oriented processes (service fulfilment system) through Web Services interfaces. These interfaces are based on Web Service Description Language (WSDL) definitions that can be integrated in client applications that are enabled to send SOAP-XML messages passed over HTTP as a transport medium. Connections to the IPSE use HTTP URL address schemes.

These service fulfillment systems connect to IPSE through a set of web services that enable them to query IPSE for information as well as request policy provisioning. The policy management components, open to interactions from service fulfillment processes through the web service interfaces, act upon the service provisioning requests and carry out the corresponding policy provisioning operations on the network resources through the network adapters.

The application-programming interface (API) uses the Extensible Markup Language (XML) with the Simple Object Access Protocol (SOAP). It includes the following functions:

• Login an authenticated user who already has an open session

• Logout a user with an open session (requesting the network element) to close it

• Get the list of activated services

• Verify the authentication status locally cached in the session data of a particular end-user

• Activate a service for a particular end-user.

• Deactivate a service for a particular end-user.

Note: For detailed information on the Web Services, refer to the IPSE Web Services Customer Feature Description, 1555-APR 901 460/2.


46 221 02-FGC 101 302 Uen C 2006-03-14

3.7 Self-Service Portal The Self-Service Portal (SSP) gives service providers the ability to showcase services, to target service offerings at specific subscribers or groups, to personalize services for the subscribers even down to a single parameter and allow subscribers to manage their own service usage.

Self-service portals are modules that interact with the Service Fulfilment Engine. This connectivity gives subscribers direct access to the Service Fulfilment Engine’s automated flow-through provisioning and group and user management capabilities.

By giving subscribers an easy way to view, self-activate and consume services and applications, self-service portals help service providers attract and retain these customers. This benefit is further enhanced by the fact that self-service portals allow service providers to showcase services in a distinctive environment. The fact that service providers share the service provisioning process with subscribers also helps reduce support requirements and the costs typically associated with these requirements.


221 02-FGC 101 302 Uen C 2006-03-14 47

3.8 Broadband Remote Access Service (BRAS) Functions IPSE uses its policy-based management framework mainly in the context of broadband remote access services to the Internet. IPSE can dynamically control services on a per-service and/or a per-subscriber basis. Dynamic bandwidth control is, among other things, one of the benefits enabling DSL Forum TR-58 type of scenarios.

3.8.1 Access System Support

IPSE supports several types of access systems including authenticated Point-to-Point Protocol (PPP), Dynamic Host Configuration Protocol (DHCP), and statically configured IP addresses over various Layer 2 mediums including Ethernet, PPP, ATM, Frame Relay, and Packet Over Sonet.

The SLC component manages the user sessions. The supported types of users accessing the broadband network remotely are as follows:

• Authenticated Users When first connected, these users need to provide a login name and password that are validated by the router network element, typically through the RADIUS protocol with an external authentication server.

• Unauthenticated Users Unauthenticated users are granted a temporary connection and session with a minimum set of IP services. They can be authenticated at a later time and be more officially logged-in by external business processes. During the confirmed login of the users, the IPSE provisions more explicit services and routing policies to the managed router.

• Persistent Users Persistent users have been pre-registered in the routers and IPSE with the identification of the Media Access Control (MAC) addresses of their terminals. Sessions are created to manage connections that have been established without requiring any explicit authentication.

When coupled with the Ericsson Ethernet DSLAM Access (EDA) network, IPSE can register persistent users dynamically by memorizing the VMAC or DHCP Option 82 identifiers.


48 221 02-FGC 101 302 Uen C 2006-03-14

3.8.2 Access-Agnostic Network Management

The Ericsson IPSE is “agnostic” to the transport medium used for broadband access. Access-agnostic network management is a result of the adoption of a policy-based framework.

The IPSE 2.0 is independent whether the access is provided over DSL or cable broadband access (currently, only DSL is supported). For instance, it manages the activity of the user sessions, unaware of their exact contexts. For broadband access services, the true nature of the Layer 2 technology used (PPP-over-Ethernet or DHCP) has been abstracted away.

The IPSE architecture uses its layered design to project a uniform and common view over all managed network resources. The semantic of the handled policies is applicable to various functions impacting the external systems; both for business and network operations.

The IPSE, in its session management for broadband access, only manages key attributes identifying a user and/or his terminal in the network: IP-address, login name, and authentication status (and record identifier if the user is already authenticated).

3.8.3 Session Management

Session management in the IPSE is used to provide a consistent view of the activities occurring within the system. The IPSE provides session management functions that allow the tracking of stateful dynamic transitions present during policy management. Time-based services, for instance, are made possible by this feature, as well as session accounting.

The IPSE handles the session management for policy rules whose enforcement requires the storage of dynamic state information (IP-Address, user login name, authentication state, and so on.)

The IPSE can either hold the full control over the life cycle of the sessions or be a synchronized slave to an external process managing master sessions.

Session management for multiple distinguished domains is supported by the IPSE. Session management in the IPSE also supports end-users to have “Single-Sign-On”.

The IPSE incorporates a dedicated database that allows various monitoring queries on the stored session information. When many IPSEs are running in a cluster, they all access a shared session database.


221 02-FGC 101 302 Uen C 2006-03-14 49

3.8.4 Handling of Authenticated and Persistent Users Initial Activity

The router is able to authenticate user logins. Normally, the router will directly issue requests to a RADIUS server. For the use case implicating a user login operation that is authenticated by the edge router, IPSE willingly accepts notifications from the trustworthy network element that user login has occurred and has already been properly authenticated.

Persistent users are pre-provisioned in IPSE and are exempted from authentication during login and session activation. IPSE is responsible for passing down the MAC address list of persistent users to the routers.

A user session is created and set as being authenticated within the IPSE. It is identified by the originating IP-address and user login information. Accounting is started by IPSE by communicating to the RADIUS server.

The appropriate routing policies specific to the authenticated user will be downloaded to the router.

3.8.5 Handling of Unauthenticated Users Initial Activity

• Login through the router can occur without any user information provided; no authentication is possible.

• The IPSE is capable of accepting notifications from the router of login operations that has occurred without any authentication.

• A session is created, void of any user information with the authentication status set to false. It is identifiable only through the originating IP-address.

• If available, a set of routing policies dedicated to the unauthenticated session will be downloaded to the router.

• Unauthenticated user sessions can be replaced by authenticated ones upon login notifications coming from business-oriented processes such as Service Portals, Customer Care Systems, or Service Fulfilment Engines.

Note: This feature is dependent on the capability of the router. Some routers do not support notification of unauthenticated user logins.

• Logouts triggered by the business-processes re-establish unauthenticated sessions within the IPSE as long as the user terminals continue to hold active IP addresses.


50 221 02-FGC 101 302 Uen C 2006-03-14

: End-User

Network Device with DHCP Server

Service Portal IPSE Resource Adapter

IPSE Policy Server

RADIUS Server

Get IP Address

Unauthenticated Login Trigger

Login

Logout Unauthenticated Trigger

Login Authenticated Trigger

Over HTTP web interaction

Redirect Us er HTTP to Service Portal

Unprovision Policies

Provision Policies

Login Unauthenticated

Create Unauthenticated Session

Login Authenticated

Start Session

Login Authenticated

Logout Unauthenti cated

Terminate Unauthenticated Session

Login Authenticated

Process Policies

Remove Poli cies

Add Policies

Create Authenticated Session

Process Poli cies

Add PoliciesProvision Policies

Start Accounting

Stop Accounting

Start Accounting

Figure 10 Unauthenticated User Login through Service Portal


221 02-FGC 101 302 Uen C 2006-03-14 51

3.8.6 Persistent User Management

The IPSE manages its own list of persistent users given a configured integration with the broadband access routers. The routing policies that are applied to persistent users are provisioned transparently within the components that are external to the core Service Logic Controller of the IPSE.

Therefore, the routers and the DHCP servers are typically configured to manage a set of persistent users who are identified by their MAC addresses and do not need to be authenticated upon every login operation and session creation.

When coupled with the Ericsson Ethernet DSL Access (EDA) network, the IPSE is able to dynamically memorize the identifiers of end-users, turning them into persistent users. DHCP Option 82 values and Virtual MAC addresses are provided through the access network.

3.8.7 Authentication of Non-Persistent Users

• The IPSE relies on an external RADIUS server for authenticated users whose connection and session establishment include login name and password identifications.

• The IPSE does not occupy a central role in the authentication of non-persistent users. It is open to different deployed environments, each possessing its own network configuration to authenticate users.

• Since the Juniper ERX BRAS, as well as the Service Portals and Service Fulfilment Engines can send out requests to the RADIUS servers, it is not a requirement for the IPSE to perform the task of issuing RADIUS Access-Request messages.


52 221 02-FGC 101 302 Uen C 2006-03-14

: End-User Network Device RADIUS Server IPSE Policy Server

IPSE Resource Adapter

Connect

Protocol includes login name and password.

Access Request

Access Accept

Authenticated Login Trigger

Login Authenticated

Verify Persistent User For non-persistent user

By MAC Address

Includes user login name and IP Address

Create Authenticated Session

Figure 11 User Authentication

3.8.8 Authentication Status Verification

The IPSE manages sessions that hold the authentication statuses of the user logins. Authentication status can be retrieved through the available User Authentication Web Service interface, part of the Service Logic Controller API, which is provided by the IPSE.

3.8.9 Routing Policy Download to BRAS

Routing policy rules that reside within the Policy Repository are communicated to the BRAS through the IPSE.

Originally fetched through the LDAP protocol from the Policy Repository, the individual policy rules or groups of rules are transformed, manipulated, and transferred within the IPSE Service Engine.

After being downloaded from the IPSE core (Service Logic Controller), the same policy information can be flexibly parsed by the individual Resource Adapters and interpreted accordingly to the protocol stack (proprietary protocol, COPS, RADIUS, SNMP, Command Line Interface) used by any


221 02-FGC 101 302 Uen C 2006-03-14 53

particular vendor’s BRAS. The Resource Adapters convert the generalized routing policies into vendor-specific, attribute-value paired configuration data to be downloaded to the network devices.

Routing policy conditions and actions that are either parameterized or assigned fixed values offer the following sample functions:

Actions:

• Per destination IP address or subnet conditions

• Per source IP address or subnet conditions

• Per from-port conditions

• Per to-port conditions

• Per distinguished IP flag(s) conditions

• Per IP protocol conditions

• For ICMP code and type conditions

• For IGMP type conditions

• Per TCP connection flag(s) conditions

• Packet marking by mask and value actions

• Packet next hop address actions

• Packet next interface actions

• Rate limit committed actions

• Burst limit actions

• Rate limit committed marking actions

• Rate limit conformed actions

• Rate limit conformed marking actions

• Rate limit exceeded actions

• Rate limit exceeded marking actions

• Peak Burst setting actions

• Peak Rate setting actions

• Traffic shaping for burst actions

• Traffic shaping for rate actions

More advanced services can be created by applying conditions. Examples of conditional services are:

• Absolute time for policy application

• Relative time for policy application

• Fixed duration of policy application


54 221 02-FGC 101 302 Uen C 2006-03-14

The availability of the dynamic routing policies is vendor-dependent. See Appendix 10 at the end of this document for further details on vendor specifics.

3.8.10 Dynamic Service Activation and Deactivation

• The IPSE allows an external business-oriented process to dynamically activate or deactivate the services belonging to a user with an established session.

• Furthermore, the Application Program Interface of the IPSE Service Engine allows business clients to retrieve the listings of subscribed services as well as active services.

Note: Figure 12 illustrates the use case for dynamic service activation and deactivation.

3.8.11 Session Termination

• When the BRAS has acknowledged that a user connection has been terminated, it is expected that a proper notification is sent to the IPSE to signal these session termination events.

• A message is sent to the RADIUS server to stop all accounting related to the login session.

• Routing policies that were provisioned in the router are explicitly removed.

• The IPSE deletes any state information related to the defunct session.


221 02-FGC 101 302 Uen C 2006-03-14 55

: End-UserIPSE Policy

ServerUser Database IPSE Policy

Repos itoryIPSE Resource

AdapterNetwork DeviceRADIUS Server

Activate Service

Login

Access Security Manager login to obta in credentials

Add Policies

Resolve User Service

Get Service

Process Pol icies

Get Policies

Provision Policies

Deactivate Service

Get Active Services

Get Subscribed Services

Resolve User Service

Process Pol icies

Remove Policies

Unprovision Policies

Logout

Reuse valid credentials

Get Services

Query Session Management

Update Accounting (Service Activation)

Update Accounting (Service Deactivation)

Figure 12 Dynamic Service Activation and Deactivation


56 221 02-FGC 101 302 Uen C 2006-03-14

3.9 Flow-Through Provisioning The IPSE Service Fulfilment Engine is a next-generation service fulfilment solution that helps carriers and automates the creation, provisioning and activations of differentiated IP services and applications. It provides a framework for service providers to manage the service delivery process that includes service definition, publication, subscription, and registration (activation).

Create

Service Descriptions

Derive Service

Offerings

Publish Offerings to Customers

Customers Subscribe to

Services

Users Register for

Services

Users Consume Services

Figure 13 Service Fulfillment Workflow Process

The Service Fulfilment Engine can interact with external systems that are likely to exist within service provider environments. These include, among others, the following systems:

• Trouble Ticket System—Errors resulting from activation errors may result in the opening of trouble tickets on an external system by the Service

• Billing System—As a result of service publication, subscription, and registration events, the Service Fulfilment Engine generates billing events that are logged and can be imported into an external billing system.

• CRM System—For service providers that have an existing Customer Relationship Management system, the Service Fulfilment Engine can be configured to synchronize end-user records through an interface or regularly schedule importing of customer information from the CRM into the Service Fulfilment Engine.

The IPSE Service Fulfilment Engine includes the following components:

• Service Framework is a powerful, directory driven software platform that gives service providers the creation, provisioning, and management of services, users, systems, equipment, and computing devices.

• Service Descriptions are configurable, modular, XML-based service templates that enable carriers and service providers to define the parameters, instructions, and service fulfilment needed to activate a service.

• Service Drivers are software modules that enable service providers to quickly integrate service offerings across a variety of equipment, technologies, and computing/application resources.


221 02-FGC 101 302 Uen C 2006-03-14 57

• Service Portal is a web-enabled application that service providers use to create self-service portals for showcasing their network, application, and personalized content services.

Note: The IPSE Service Fulfilment Engine includes SFE applications used to manage and monitor service fulfilment tasks such as deploying services, offering services to customers, managing customers’ service accounts, and monitoring the SFE server(s). For detailed information on SFE applications, refer to the Architecture section.

3.9.1 Order Management Interactions

IPSE's open APIs and architecture provide a number of integration points for external OSS applications, such as CRM, billing and inventory systems. IPSE facilitates integration using a variety of methods including:

• Web services

• OSS/J adapters

The IPSE allows the modeling of web services aligned with other existing OSS components that call these web services. Web services are, by nature, distributed across the network and, in general; do not require any additional infrastructure than the components already in place.

It is also possible for third-party systems to interface with IPSE using OSS/J (which uses session and message-driven EJBs). Fundamentally, the OSS/J mechanism is different from the web services model considering it is using a message-driven common bus. A common bus has the advantage of offering a more centralized and better-controlled solution. It is, for instance, possible to log/audit, authorize and monitor the traffic flow of method calls. However, it requires more infrastructures and is more limited from a scalability perspective.

Professional services need to work with the operator to understand the business processes involved and to propose a solution that efficiently integrates IPSE in existing OSS ecosystems.

3.9.2 IPSE Service Fulfillment Engine Functions

The functions of the IPSE Service Fulfilment Engine within the service life cycle include:

• Service definition by the service provider

• Notification of service availability to subscribers via a service portal

• Subscription to the service either by the subscriber through a portal or customer order center

• Verification that resources are available and, if necessary, reservation of the resources required


58 221 02-FGC 101 302 Uen C 2006-03-14

• Creation, authorization, and authentication of subscribers

• Address management via DHCP and DNS

• Service activation via deployment of QoS and security policies into a service switch or other node

• Accounting at the session level including exporting data to databases, billing mediation, charging, and rating engines

• Working with network management fault and performance management tools

• Session termination at logout


221 02-FGC 101 302 Uen C 2006-03-14 59

3.10 Service Management Services are a set of policies that can be launched at the speed of demand by creating a unique library of service offerings tailored to meet the changing needs of businesses and consumers. It is also possible to cost effectively trial new services with selected groups of subscribers, by quickly being able to alter parameters to optimize the service offering. Services templates can be created and modified without disrupting services to existing subscribers. New services can be easily and inexpensively tested prior to deployment.

Different services can be subscribed to by end-users. The Service Portal presented to the subscriber is dynamically generated from information stored in the subscriber profile. The Service Portal presents the user with personalized services and service offerings. The portal presents the subscriber with the available options, such as differentiated class-of-service Internet access or dynamic selection of value-added content service. A customer subscribes to a service, which is defined with parameters for description, billing and policies.

IP Service Engine (IPSE) provides the functionality required to control the IP services on a session-by-session basis. It tracks the subscribers' service profiles and configures the underlying nodes to deliver those services at the establishment of a communication session delivered over a broadband, IP network. After subscribers activate their service, the routers operate according to the established policies.

IPSE enables operators to build new, differentiated services by combining resources like bandwidth and content with control based on parameters such as time, volume and type. Variables can be used in policies, giving the operator the freedom to adjust values for bandwidth, speed, or time when required

Services are defined and managed through the IPSE OAM interface and the Service Fulfilment Engine applications.

3.10.1 Predefined Services

• Tiered bandwidth: Tiered bandwidth services are several service levels with bandwidth increments. An example of a service offering could be a Bronze service with 512 kbit/s, Silver service with 1 Mbit/s and Gold service with 2,5 Mbit/s. IPSE allows for completely customized services and for easy, dynamic upgrades.

• Turbo: Short-burst service. IPSE enables the operator to apply an expiration condition type that sets the time duration of a service. For example, a booster button service can be created for end users that require a quick burst of additional bandwidth.


60 221 02-FGC 101 302 Uen C 2006-03-14

• Access List: A service (s) that can be tailored to protect an end-user’s PC through port and IP address filtering.

• Login/Mandatory: For IPSE solutions integrated with the Service Fulfillment Engine, it is possible to create the following services by simply adding an attribute:

• A login service that is automatically activated at login for a designated subscriber

• A mandatory service that is automatically activated for all users in a domain when they log in

• Mutually Exclusive: The OAM tool enables you to create service groups, in which the individual services within each group are mutually exclusive of each other. Regardless of the number of services contained within a designated group, an end-user can only activate one service at a time. For example, an Internet Service Group might contain three services that are based on bandwidth allocation. For such a group, the concept of mutual exclusivity eliminates the problem of similar IP services competing against each other and possibly degrading quality.


221 02-FGC 101 302 Uen C 2006-03-14 61

3.11 Policy Management The IPSE follows a policy-based framework designed from a higher level of abstraction over traditional management techniques. The intent is that the service developers create policies that determine the desired goals of the networks rather than specific procedures. These policies are provisioned, processed, controlled, and managed by the IPSE policy-based framework, which, binds them with the current network state, transforms them into dynamic configuration data, and sends them to network devices such as an edge router, determining their behavior.

The IPSE policy-based framework allows, in addition, access and service providers to use these policies to define specific services that end-customers can subscribe to. The services may be then offered under different business models and network architectures.

Policy-based network management has arisen as a pledge technology for managing networks, distributed systems and enterprise-wide applications. It is based on high-level policies that define the desired behavior of the network. These policies define what the network is supposed to do, rather than how is it going to do it. It is largely influenced by standards organizations such as the Internet Engineering Task Force (IETF) and the Distributed Management Task Force (DMTF).

As such, it is possible to eliminate, at the design phase, some of the details that will be present in the end configuration parameters; for example, the exact bindings to user information such as an Internet Protocol (IP) address, application port number, ingress interface, and so on.

Policies are high-level rules that determine the behavior of the resources, and the network as a consequence.

This higher level of abstraction simplifies the management of large-scale networks and enterprise-wide applications, and the automation ensures the consistency and integrity in the resources’ behavior across the network. The dynamic binding of policies within the IPSE policy-based framework allows network types of policies to be introduced more easily. A policy can be changed dynamically, thus changing the behavior of the managed resource without modifying the implementation or interrupting the resource's operation.

The key benefits from using a policy-based approach in the IPSE are:

• Improved Flexibility Flexibility is obtained by separating the services and policies from the actual implementation of the managed resources. Different types of services are also supported.

• Improved Scalability Scalability is improved by uniformly applying the same service and policy to large sets of resources. The IPSE policy-based


62 221 02-FGC 101 302 Uen C 2006-03-14

framework is flexible in that it provides the necessary abstractions to manage a variety of resources, with different capabilities and limitations, from different vendors. It also defines how the network's resources are to be allocated among its clients. Clients can be individual users, departments, host computers, or applications.

3.11.1 Policy Management Function

Services are defined by the grouping of different policies. Policies may be reused by different services. Hence, services may be created, substituted and modified at lower cost, and more rapidly.

IPSE provides policy management to enable different services to be provisioned on an edge routing device; for example, ERX-series router, . This enables the Service Provider (SP) to define policies, thereby controlling the network traffic for the subscribers based on their subscriptions.

The Policy Management Tool (PMT) provides the Service Provider (SP) with the ability to define and modify policies through a GUI, and to store the policies in the Lightweight Directory Access Protocol (LDAP) directory. An operator that understands the capabilities of the router (for example, the filtering and classification processes) can easily build policies. The PMT simplifies the management process by allowing the network administrators to validate and verify that the rules do not conflict when they are combined to make a policy. The PMT is specialized for creating routing policies that are divided into two classes: egress (outgoing traffic) and ingress (incoming traffic). The resulting policy information is stored in the Policy Repository. At any time, you can view a summary of an existing policy group. The Policy Management Tool (PMT) is deployed within the same web binary archives as the OAM GUI. It is a sub-component of the OAM GUI.


221 02-FGC 101 302 Uen C 2006-03-14 63

Figure 14 Policy Management Tool (PMT)

The resulting policy information is stored in the Policy Repository. Given the Policy Management Tool’s validation processes, all policies are fully operational from the start.

3.11.2 Bulk Provisioning of Services and Policies

IPSE Bulk Provisioning provides for bulk-importing capabilities that allow large sets of services and policies to be imported from a single external source, such as an XML document.

Note: This causes a high load in the IPSE and should be restricted to maintenance window activity.

Bulk provisioning is provided through batch files that are fed from the IPSE SFE into the IPSE Policy Management Tool. The batch files hold policy information that is formatted in the Directory Service Mark-up Language (DSML) or the LDAP Data Interchange Format (LDIF). The IPSE possesses complete logging facilities to record run-time traces on the node machine.

Subscriber and service per subscriber is also possible to provision through bulk import. The bulk service provisioning feature is very useful in scenarios where the service provider has signed up a large number of customers.


64 221 02-FGC 101 302 Uen C 2006-03-14

3.12 Session Management A service session is established when a policy is applied. A service session is associated with a particular subscription. When a subscriber session is active, service sessions are established by applying a policy to the interface associated with the subscriber. Accounting is started upon the enforcement of policies that correspond with the creation of a state-full session (for example, IP connection login). It is stopped when the session is terminated by timely events (e.g., user IP connection logout, administrator intervention) IPSE enables operators to control IP services on a session-by-session basis. Session data is dynamically provided by external events and procedure calls originating from either the business web services or network resource adapters. The OAM Tool enables operators to perform session management functions such as:

• Session Monitoring and Live Tracing: "Live tracing" of individual session operations and data is a form of logging that is available in the IPSE. The logging information returned is focused on the individual activity of each session. Separate log files are generated for each monitored session, and are dynamically updated.

• Localized (Domain-Specific) Session Management: IPSE handles the session management for policy rules whose enforcement requires the storage of dynamic state information (IP-Address, user login name, authentication state, and so on.) It is possible to group all active sessions related to the same IP domain together. Session management for multiple, distinct domains is supported by the IPSE. The IPSE incorporates a dedicated database that allows various monitoring queries on the stored session information. When many IPSEs are running in a cluster, they all access a shared session database.

• Activating or deactivating services associated with the session

• Terminating a session and session logging.

• Archiving and Recovery: It is possible for the operator to create a backup dump of all live sessions, which store all of the current session state-full information to a backup file. To initiate recovery procedures, the operator can load a session backup dump that has been created earlier. This restores the session states for all the previously connected subscribers.

IPSE supports a Single Sign-On (SSO) service. Single Sign-On enables end users to authenticate themselves only once per session. For example, an end-user does not have to log in again into the Service Portal if IPSE already has knowledge of the user session and it is authenticated. IPSE also allows automatic registration of persistent users that are connected through the Ericsson EDA access network to an IPSE-controlled BRAS router. Persistent users are able to login through the same access


221 02-FGC 101 302 Uen C 2006-03-14 65

network without requiring user name and password validation, even through multiple subsequent sessions.

3.13 Operation & Maintenance

3.13.1 OSS Support

IPSE can be tightly integrated with existing OSS infrastructures to meet the most demanding customer requirements. The IPSE Service Fulfillment Engine offers several integration methods to interoperate with the different types of OSS infrastructures from proprietary to standard based.

Flexible Integration The Service Fulfilment Engine’s open APIs and robust architecture provide a number of integration points for external OSS applications, such as CRM, billing, and inventory systems. The Service Fulfilment Engine facilitates integration using a variety of methods, including:

• Web services

• OSS adapters in the form of Java components

• Client-side Java library

Ericsson professional services can help to integrate IPSE to the existing OSS infrastructure by modelling the web service APIs of other OSS and business processes that call those web services.

It might alternatively be required to model and implement Java components that directly interact with other OSSs, using the transport methods that are supported by those systems. These components, when deployed on the Service Fulfilment Engine, are exposed as web services and run under servlets. Java components can also be exposed as web services.

The Service Fulfilment Engine provides the ability for other OSSs to integrate with its API using a client-side Java library. It also enables third-party systems to interface with external systems using OSS/J (which uses session and message-driven EJBs).

3.13.2 Web-Based Service Provisioning and Configuration

IPSE provides a suite of web-based Graphical User Interfaces that allow system administrators to perform domain, policy, service, session, security, and node management. The web-based interfaces are composed of dynamic HTTP pages managed by a web server.


66 221 02-FGC 101 302 Uen C 2006-03-14

Table 1 Web-Based Interfaces

Service Portal The Service Portal is the entry point for customers. The service portal provides self-service capabilities to customers.

System Administration Application (SAA)

The IPSE System Administration Application (SAA) enables you to manage the data required to create users, equipment and services. It also allows you to manage the various stages of service definition and delivery (offer IP services, create service offerings, and provide self-service provisioning support).

Service Deployment Application (SDA)

The Service Deployment Application (SDA) is a web-based application that allows service provider administrators to deploy services and service building blocks to the IPSE Service Fulfillment Engine, where they can be activated for customer use

Service Offering Application (SOA)

The Service Offering Application (SOA) is a web-based application that allows service provider administrators to define the commercial terms and billing information associated with a service, in the form of a Service Offering. This occurs after a service has been deployed to the Service Fulfillment Engine.

Service Provisioning Application (SPA)

The Service Provisioning Application (SOA) is a web-based application that gives Customer Service Representatives (CSRs) the ability to manage customer accounts and fulfill customer requests.


221 02-FGC 101 302 Uen C 2006-03-14 67

Operations and Maintenance (OAM) GUI

Service Management - The OAM GUI provides a service control function to support the creation and delivery of services. Tasks include adding, editing, deleting, and enabling or disabling services, as well as creating mutually exclusive (MUTX) service groups.

Policy Management Tool (PMT) - Policies define the actual behavior of services managed with the IPSE System Administration Application. The Policy Management Tool (PMT), a sub-component of the OAM GUI, is a web-based interface that allows administrators to manage, create, modify and delete policies.

Session Management - Session management tasks include session browsing and tracing individual session operations. Session logging can be added, viewed, deactivated, or deleted.

Domain Management - Domains can be added, enabled, or disabled. The management of domains can only be performed by root users or users with privileges.

System Management - The system management function enables you to configure nodes and domain(s), as well as view the status of alarms and performance counters.

System Dashboard The System Dashboard is a web-based application that gives IPSE Service Fulfillment Engine administrators the ability to monitor and update the status of multiple Service Fulfillment Engine servers and applications from a single location.


68 221 02-FGC 101 302 Uen C 2006-03-14

3.13.3 License Management

Strict licensing mechanisms control software features whose functionality is either optional or graded in terms of capacity or fullness. The License Manager acts as the authority by which other components in the Service Engine make reference in order to discover the level of functionality that is allowed for their respective features. The License Manager component is actually a proxy front-end to obtain the configurations and permissions for the licensed product features.

3.13.4 Web-Based Graphical User Interface for Platform Management

The Java Management eXtension framework (JMX) available in the J2EE application server automatically binds the deployed managed beans (Mbeans) to a web-based Graphical User Interface console. Mbeans are software-deployed components that can be deployed individually, started, and stopped as application services within the application server. The internal interfaces of Mbeans can be extended with application behavior that can be invoked through the JMX graphical console.

All of the IPSE Service Logic Controller’s component are modelled and packaged as JMX Mbeans.

It is, therefore, possible to view and control the internal statuses and data of modules handling the policy management, session management, and resource adapter handling of the IP Service Engine.

3.13.5 Network Management System

A Network Management System (NMS) can monitor IPSE and receive events via the Simple Network Management Protocol (SNMP V3.0). The SNMP services available to operators, administrators, or maintenance personnel include:

• Fault Management: Sends asynchronous alarms generated by IPSE to the NMS to alert an operator of a fault condition.

• Performance Management: Collects performance data at predefined intervals that operators can retrieve to assess and fine tune IPSE during normal operations

IPSE counters and alarms can be retrieved from a single interface such as Adventnet via SNMP.

IPSE consists of the following NMS features:

• The SNMP Agent is started up as part of the IPSE operating environment. When it starts, it reads configuration information from the snmp.xml file.


221 02-FGC 101 302 Uen C 2006-03-14 69

• The IPSE components register with the Alarm Manager for alarms and counters. The Managed Objects (MOs) within IPSE represent the different components of IPSE and reflect different attributes that are monitored.

• The SNMP Agent receives alarm notifications from the Alarm Manager.

• The SNMP Agent responds to SNMP requests from the NMS and processes the SNMP command.

• The SNMP Agent reports alarms generated by the IPSE components through SNMP notifications to the NMS. Alarm notifications are also reported to the ipse.log file. Performance data is also collected and forwarded by the SNMP Agent, but only in response to a Get command from the NMS.

3.13.6 Logging

The IPSE possesses complete logging facilities to record run-time traces and faults as textual inputs within files residing on the node machine. Logging information reveals printouts that are useful for informational, debugging, or error handling purposes. Since logging can affect the system performance, it can be localized for specific types of information, and it can be configured to output more or less data. The format in which numerical or complex data is presented is configurable. Log files are controlled with size limits. When a file surpasses the specified maximum size, a new file version is created in the file system.

“Live tracing” of individual session operations and data is a more sophisticated form of logging that is available in the IPSE. The information returned in the logging is focused on the individual activity of each session. Separate log files are generated for each monitored session, and are dynamically updated. The selection of the exact set of sessions to be monitored is performed through a web-based interface bound to the JMX management console.

3.13.7 Performance Statistic Counters

Performance counters for various system-level criteria are accessible through the SNMP interface of the IPSE. The counters can represent bare values or averages calculated from summations accumulated over a fixed time period.

For a detailed list of the counters, refer to the IPSE 2.0 Feature Description, 1/1221 04-FGC 101 302.


70 221 02-FGC 101 302 Uen C 2006-03-14

3.13.8 Alarms and Notifications

Alarms and notification for system-level errors or noticeable events are sent through the SNMP interface. They constitute the fault management functions of the IPSE. It is assumed that these outbound notifications from the IPSE are logged and managed by an external client application.

For a detailed list of the alarms, refer to the IPSE 2.0 Feature Description, 1/1221 04-FGC 101 302.

3.13.9 Remote Software Upgrade

Software binaries are deployable at run-time in an application server with great ease, requiring little intervention from the system administrator.

The binaries are packaged as archived files compressing entire directory structures that hold individual byte-code classes and deployment descriptors. The deployment descriptors provide the necessary information for the load and execution process to be greatly automated by the application server. Dependencies between modules and external libraries are properly defined. Thus, any ordering of the deployed software packages is managed autonomously. The entire software archive may be re-deployed by substituting the file with another version.

Un-deployment of the IPSE application is obtained by removing the software binary archive from the deployment source of the application server.

The software binary archive files are transferable to the application server’s machine through the FTP protocol.

Note: Some third-party components may not be easily upgraded without requiring a run-time interruption and restart.

3.13.10 Archiving

It is possible for the operator to create a backup dump of all live sessions, which stores all current session state-full information to a backup file.

3.13.11 Recovery Procedures

To initiate recovery procedures, the operator can load a session backup dump that has been created earlier. This restores the session states for all previously connected subscribers.


221 02-FGC 101 302 Uen C 2006-03-14 71

3.14 Multi-Vendor Support The IPSE carries out policy provisioning operations on the network resources through a set of modules called Resource Adapters (RAs). Each RA handles a specific type of resources and uses resource-specific high and low-level protocols to communicate with the managed resource. This approach makes the policy processing in the Service Logic Controller “agnostic” to the specifics of the network elements. Multiple resource adapters, that is, one resource adapter per type of resource, can be incorporated into the IPSE. This capability enables policy management components deployed on the Service Engine to communicate with the underlying resources.

The capability to manage various network resources from different vendors in disparate networks (access, edge, and so on) is a feature that grants enormous flexibility and value to the IPSE solution. This allows Ericsson IPSE to be deployed in a multi-vendor network as the only control point.

3.14.1 Support for Multiple Domains

IPSE supports multiple domains. For each domain, a single IPSE can be configured to connect to distinct LDAP and RADIUS servers. The multiple domain support provided by IPSE includes functionality for remote user authentication, service authorization, and accounting.


72 221 02-FGC 101 302 Uen C 2006-03-14

3.15 Wholesale/Retail Management IPSE enables access operators to support both the wholesale of access services as well as retail sales of Internet access and content services. In a multiple domain network, IPSE allows an access operator to act as both access provider and service provider offering subscribers tailored services according to their needs. When present in a wholesale solution, the IP Service Engine enhances it by offering dynamic IP services and specialized control over the access and edge networks. Operators and ISPs benefit from the added capabilities of the IPSE.

Without a network operator or a wholesale solution, each retail ISP would build, own, and manage its own service deployment infrastructure. Using the wholesale solution, the wholesale operator owns and maintains the network infrastructure for service deployment and grants access to the subscribers of the service providers. This lowers the barrier of entry for retail operators while increasing the utilization of the wholesaler’s investment.

The Service Fulfilment Engine supports wholesale/retail models with key features such as

• Customer and Subscriber Partitioning

• Service Control

• Virtual Engines

• Security Administration

• Dynamic User Profile Lookup

• Mapping to Virtual Routers

• Session Management

• Policy Management

• Service Management

• Accounting

• Wholesaling of IPSE Service Fulfillment

3.15.1 Customer and Subscriber Partitioning

The Service Fulfilment Engine’s user management object hierarchy allows considerable flexibility in the creation and organization of retailer groups, retailers, subscriber groups and subscribers. For example, multiple nested levels of subscriber groups can be created, which can be used to represent channels, master channels, individual retailers, and their subscribers. In a wholesale/retail scenario, a wholesale provider can create a retailer group for each of its retailers. Each of these retailer groups contains the subscriber objects required to manage the retailer’s


221 02-FGC 101 302 Uen C 2006-03-14 73

subscribers, including services, subscriber groups and subscribers. Wholesalers can also create master channels that are composed of multiple retailers.

3.15.2 Service Control

The Service Fulfilment Engine provides flexibility in publishing Service Offerings to subscribers. Using the Service Deployment Application, administrators can publish services to:

• All retailer groups

• Individual retailer groups

• Individual retailers

• Subscriber groups

This flexibility allows wholesalers to publish services to all of its retailers and, when required, to a specific retailer, or even to a retailer’s individual subscribers. Once a service has been published to retailers, retailer administrators can then accept the service by subscribing to it on behalf of their organization.

3.15.3 Virtual Engines

A single IPSE can be partitioned into separate virtual engines, each virtual engine associated with a particular domain. Core functionalities such as policy management, session management, logging, user profile lookup and accounting can be configured differently for all users and services belonging to a particular IP domain. For each domain, a single IPSE can be configured to connect to distinct LDAP and RADIUS servers. Virtual engines within the IPSE support the wholesale model of services whereby an operator provides a network infrastructure that is shared by many independent service providers.

3.15.4 Security Administration

In the area of security administration, the Service Fulfilment Engine allows wholesale providers to assign a retail administrator profile to each retailer group. As a result, each retailer’s administrator has full access to its own subscribers, but not to other retailers’ subscriber objects.

The wholesale solution offers use of the L2TP tunnelling technique or use of virtual routers.


74 221 02-FGC 101 302 Uen C 2006-03-14

3.15.5 Dynamic User Profile Lookup

It is possible to configure the IPSE to perform a lookup for user profiles on different LDAP directory servers for each ISP, based on an associated service domain name.

The LDAP directories may be hosted by the wholesale network operator or located remotely at in the ISP private network.

3.15.6 Mapping to Virtual Routers

Domains can be mapped to a Virtual Router (VR) on the BRAS. Each Virtual Router can be pointed to its own RADIUS or DHCP server, allowing for the functional appearance of a completely separate router. This is particularly valuable for wholesale environments, where Service Providers may host a number of ISPs on any given router, with each ISP wanting to target its own RADIUS database.

IPSE uses the concept of service domains to divide the distinct virtual elements in its system.

In the IPSE, core modules that can be made virtual and managed individually as separate service domain functions are:

User Data Management

Session Management

Policy and Service Management

Authentication

Accounting

IP Service Fulfilment

3.15.7 Session Management

End-user session information is segmented per service domain in the IPSE. This gives an ISP the possibility to perform queries and monitoring on the specific set of sessions related to a customer.

Quotas on the maximum number of sessions for each domain can be configured.

Performance management statistics and alarm management may be configured to be on a per-domain basis. Hence, an ISP may integrate its own network management system to the ISP and obtain valuable data from the leased BRAS.

Session-based logging is a possibility in the IPSE. Logging can be filtered and scoped on a per-domain basis.


221 02-FGC 101 302 Uen C 2006-03-14 75

3.15.8 Policy Management Network policies are stored in a central repository within the IPSE. Policies are independent from the service domains and can be shared and reused by services and their providers. The wholesale operator has the option of defining and maintaining exclusively the policy repository or grant external clients (ISP) to define new policies themselves. Note that the latter option needs strict procedures for security, administration authentication, validation and testing to be implemented by the operator. External clients such as ISPs use the web-based IPSE Policy Management Tool (PMT) to view or edit the available policies. In the operator’s network, the policy repository is managed in an LDAP directory that is private to the outside world.

3.15.9 Service Management Service associations with policies can be managed individually for each domain. Each ISP can maintain its own set of available services within the IPSE. The storage of the service management results can be addressed to separate LDAP servers that are specific to different domains. LDAP directory storing service management data can be hosted by the wholesale operator or externally in the network of the ISP

3.15.10 Accounting RADIUS accounting is often paired with the same server resources as for the authentication function. In general, authentication and accounting share the same database (AAA database). However, it is always possible to deploy separate RADIUS servers to handle accounting. The accounting RADIUS may store its persistent data in a separate data store such as a Relational Database Management System (RDBMS). The IP Service Engine is able to maintain individual setups for accounting for each service domain.

3.15.11 Wholesaling of IPSE Service Fulfillment The wholesale business model is also applicable in the service layer. The IPSE broadens the offerings of a network operator, most particularly in a wholesale deployment where, in addition to the network infrastructure leased to ISPs, service applications hosted by the wholesale operator can also be used by the ISPs. These ISPs may not want to invest in new infrastructure required to build and maintain new IP services. In this case, the network operator acts as an ASP. The ISPs can be relieved of the job of user/service management since the Service Fulfilment Engine (SFE) manages the complete lifecycle of services (their creation, publication, and deployment).


76 221 02-FGC 101 302 Uen C 2006-03-14

3.16 Security Aspects The IPSE supports various levels of system administrators with different levels of authorization. For network security, all administrators who log in to the IPSE must be authenticated. The administrator login is automatically timed out after a period of inactivity. Any subsequent request from the same client then needs to pass authentication again. This ensures that the IPSE has a high level of flexibility and security with respect to management subscribers.

For client security, each client is authenticated for source and content of the request, ensuring that only access from designated clients is authorized. Clients such as business-oriented processes interacting with the Service Engine need to log in through the available Application Program Interface and obtain a valid credential. The credentials are generated specifically from the client's IP-domain.

Network element security is provided as the network elements are protected by authentication and authorization mechanisms to prevent any unauthorized access. The interfaces for access external to a controlled enterprise network can be secured by using the Secure Socket-Level (SSL v2/v3) or the newer Transport Layer Security protocols (TLS v1).

For multiple IP-domain configurations controlled by separated administrative entities, such as a deployment supporting the wholesaling of IP services, security constraints are managed independently. Hence, separate administrator accounts with limited privileges and areas of jurisdiction are available in the IPSE. The IPSE may be configured to authenticate administrators belonging to different Internet Service Providers through several RADIUS servers. The external RADIUS servers may occupy central roles or serve as redirecting proxies to other RADIUS servers.

The available system administration interfaces provide direct access to the data in the LDAP directory. For access to LDAP, the built-in security and access controls in the LDAP server are used. Traffic to and from the directory is secured through Secure Sockets Layer (SSLv2/v3)-based security. LDAP requests from IPSE to one or more directory servers are frequent. The web portal uses SSL through HTTPS. The RADIUS server handles logging into the system as a subscriber.

IPSE requires secure login procedures for each of the following interfaces:

• OAM GUI (Policy Management Tool (PMT)

• Service Fulfilment Engine GUIs (SAA, SPA)

• RADIUS Client


221 02-FGC 101 302 Uen C 2006-03-14 77

3.17 Redundancy The Ericsson IP Service Engine is configured for redundancy, abiding as much as possible to the many prerequisites for the “telecom-grade” qualification.

A single system has no single point of failure, both for hardware and software components. However, it is important to understand that IPSE is integrated, in most cases, into existing customer infrastructures and that these infrastructures must comply with some redundancy requirements prescribed by the IPSE redundant solution. For instance, IPSE often needs to integrate with existing RADIUS infrastructures for use cases requiring AAA functionality. Consequently, IPSE is dependent on the existing customer’s RADIUS infrastructure to provide a redundant solution.

The platform used by the IPSE is comprised of Sun SPARC servers running the Solaris UNIX operating system. Redundancy is applied on all application running processes. Hardware such as servers, storage disks, network interface cards on each server, cable connections, and switches have redundant components

Some of the principal capabilities of IPSE network redundancy include:

• Secure traffic distribution through SSL

• Static and dynamic load balancing to maximize availability and performance

• Fail-over redundancy

• Separate Virtual LANs (VLAN) providing a topology that isolates IPSE nodes from the rest of the customer network

• Intelligent traffic distribution and monitoring to determine IPSE node availability, including traffic re-distribution in the event of node failure.

• SNMP support for centralized fault management from a Network Management System (NMS) to report IPSE node status

3.17.1 Hardware Redundancy

Hardware redundancy is obtained by running the software on more than one machine. As long as there is one server that is operational, change-out or maintenance is possible on the redundant node. The hardware maintenance varies depending on the type of servers selected (NEBS/Non-NEBS) as NEBS hardware provides front accessible hot-swap capability.

Note: IPSE relies completely on the availability features of the connected access router hardware. Solutions for the latter may greatly vary from one


78 221 02-FGC 101 302 Uen C 2006-03-14

vendor to another. For instance, Juniper’s solution engages the control software of a failing router to automatically upload its activity over to other devices software control, configured in the same cluster.

3.17.2 Software Redundancy

The IPSE strives to have data fault-tolerance. The IPSE Service Logic Controller maintains all state-full data in an external persistent store. In the eventuality that the Service Logic Controller crashes, a minimum of data is lost. Data stored in the database remains safe. For the most part, the data saved by the Service Logic Controller is related to session management as well as accounting records.

The separate persistent store typically supports distributed transactions respecting ACID characteristics: atomicity, concurrency, integrity, and durability. To be open to the best cost-effectiveness, IPSE is open to any types of database implementation, whether object–oriented or Relational Database Management Systems, distributed or not.

External nodes, with which the IP Service Engine shares interactions, are expected to have fail-safe features. For LDAP and RADIUS servers, the IPSE switches to a back-up secondary node, following a failure to communicate to the master primary applications.

Resource Adaptors are configured to communicate to several network devices at the same time. Upon the detection of a failure to communicate with a specific router, for example, and keep-alive messages do not return any acknowledgement, the Resource Adapters dismiss the router device and divert all provisioning attention to the ones that remain alive.


221 02-FGC 101 302 Uen C 2006-03-14 79

4 Solutions

4.1 Overview IPSE is an IP service delivery platform that provides enabler functionalities allowing for the quick and efficient delivery, provisioning and control of IP services. These enablers are the IPSE core functions.

These core functions alone do not provide saleable services. In order to offer a complete solution to a particular customer, the following elements are required:

• Set of IPSE core functions (Essential)

• Feature-specific logic binding the core functions in an exploitable service (Essential)

• Customization of the feature to the particular business processes of the operator (Optional)

• Integration of the feature with the existing customer’s OSS and network infrastructure making a viable solution (Mandatory and varies case-by-case)

IPSE proposes a library of pre-packaged features ready to be trialed, integrated as-is or customized to the particular business processes of existing customer infrastructure.

The strategy is to provide a set of features that allow for quick and seamless integration of new types of IP services, with the objective of minimizing the so-called “integration tax”. Depending on the business processes and infrastructure’s maturity with respect to the OSS and the access network in place, the integration effort will vary on a case-by-case basis. For instance, green field type of operators will, in general, require a smaller integration effort considering their business processes and infrastructures are not yet fully established. However, considering the pre-packaged features are developed with the widely adopted eTOM business process framework in mind, integration even in more mature OSS infrastructure is reduced to a minimum.

It is also possible to develop a fully customized solution dedicated to the specific requirements of a particular customer. The goal, in this case, is to offer a turnkey solution that could tightly integrate and interoperate with a proprietary or homegrown type of infrastructure. These types of integration projects are obviously detailed on a case-by-case basis, whereby Ericsson professional services would deliver, install and integrate according to the specifications of the artifacts.


80 221 02-FGC 101 302 Uen C 2006-03-14

4.2 IPSE in Broadband DSL Networks IPSE is positioned as an enabler of multi-service and multi-edge broadband DSL access networks. As depicted in Figure 15, IPSE can provision and dynamically control Network Elements including Intelligent Service Edge nodes. It also allows management of wholesale between access and service providers as specified in DSL Forum TR-58/59 and WT-102.

IntelligentService Edge

IntelligentService Edge

BroadbandEthernet Network




L2/L3 RegionalNetwork

L2/L3 RegionalNetwork

BroadbandATM networkBroadband

ATM network

ATM DSLAMATM

DSLAM

IPSEIPSE

Residential AccessResidential Access

Enterprise AccessEnterprise Access

Legacy Access

Ethernet Switch

Ethernet Switch

MSANComboMSANCombo

InternetInternet

Service ProviderEdge

Service ProviderEdge

ISP1ISP1

ISP2ISP2

ATMSwitchATM

Switch

IPDSLAM

IPDSLAM

IPDSLAM

IPDSLAM

Business & Residential Fixed Wireless:Ethernet Wireless Access (WiMAX)

))))))))))))

Business & Residential Fixed Wireless:Ethernet Wireless Access (WiMAX)Business & Residential Fixed Wireless:Ethernet Wireless Access (WiMAX)

))))))))))))

PEMPEM

IP/MPLS

PPP/L2TP

VLAN

IP

Local Loop Service ProviderAccess Provider

EdgeRouterEdge

Router

EthernetGatewayEthernetGateway

BRAS(ERX)BRAS(ERX)

Figure 15 IPSE in Intelligent Service Edge Network


221 02-FGC 101 302 Uen C 2006-03-14 81

4.3 IPSE in Multi-Service Reference Architecture The long-term vision for IPSE's role in multi-service networks is exemplified by the TR-58 multi-service reference architecture, where the common enabling service layer has been broken down into two sub-layers, namely Network Management and Network Control layers. The Network QoS Control and the Service Management components are available in IPSE 2.0. The Network QoS Control provides the ability to dynamically control services offered on edge nodes like bandwidth management service for instance. Note: Resource Admission Control is not available in IPSE 2.0. This component is reserved for future release in IPSE 2.1. The Service Management component enables static provisioning of Network Elements and Applications. It includes a flow-through workflow-based provisioning function. This component is used to provision the following solutions in the scope of IPSE 2.0

• Business VoIP • Residential VoIP • EMM 2.1 • EDA Provisioning Solution

It is important to note that the solution portfolio is constantly expanding with the constant addition of new IP-based services.


82 221 02-FGC 101 302 Uen C 2006-03-14

4.4 IPSE in eTOM Business Process Framework The eTOM Business Process Framework categorizes all the business activities that a service provider will use during the life cycle of particular service. This exhaustive model receives a lot of attention and adoption from the telecommunication industry.

This framework specification provides a basis for the development of standard interfaces and data models defined by the Telemanagement Forum NGOSS activities. These efforts are paving the way to simpler OSS/BSS development and integration.

The long-term ambition for IPSE is to overlap completely the 9 bottom left boxes. As it stands today, IPSE 2.0 addresses partially this solution space as depicted in Figure 16. The main area covered by IPSE today is in the Fulfilment vertical process and the Service Management & Operations, and the Resources Management and Operations horizontal processes.

IPSE IPSE IPSE

Figure 16 IPSE in eTOM Business Process Framework


221 02-FGC 101 302 Uen C 2006-03-14 83

4.5 Predefined Solutions IPSE supports predefined solutions that allow for quick integration of new revenue-generating services. It is important to note that these solutions need a certain level of customizations and integrations. It is not the mandate of this document to either enumerate or quantify these activities as they are on a case-by-case basis.

The predefined solutions are all available as optional items that can be installed on top of the Service Framework.

Prerequisites The following prerequisites are required for the solution to be installed:

• IPSE Service Framework

Predefined Solutions Table 2 presents the various solutions currently available in the scope of IPSE 2.0.

Table 2 IPSE Predefined Solutions

Solution Description Sales Object

Dynamic control of session based services

This solution allows for dynamic control of the parameters of a particular network session. For instance, tiered bandwidth and turbo button

Service Description -Broadband Access

Resource Adaptor -Juniper E-Series

VoIP This solution allows for the static provisioning of VoIP solutions

Note: For detailed information on the provisioning of VoIP solutions, refer to the IPSE 2.0 Feature Description, 1/221-FGC 101 302.

Service Description -Business VoIP

-Residential VoIP

Resource Adaptor -Broadsoft

-Sylantro

-Tekelec

Redundancy This solution provides a redundant solution featuring no single point of failure.

Service Framework Options

-High availability (4+4)




84 221 02-FGC 101 302 Uen C 2006-03-14


221 02-FGC 101 302 Uen C 2006-03-14 85

5 Architecture The IPSE system bridges the service layer and the network layer. At its core, the IPSE system provides a policy-based framework that interacts with elements belonging to the service and network layers. This section examines the components that comprise the IPSE system.

IP Service Engine

Service FulfilmentEngine

Service LogicController

Self-Service Portal

User/ServiceDatabase

PolicyRepository

SessionDatabase

OSS/BSS OSS/BSS

Application & Network Element

Provisioning

NetworkElementControl

NetworkElementControl

Authentication & Accounting

Resource Adapters to Dynamically Control NEs(e.g.: BRAS).

Integration with CRM, OMS, NRM, Billing, etc

Integration with AAA (RADIUS)

Network Management Layer

Network Control Layer

Network Layer

Figure 17 IPSE 2.0 Main Architectural Components


86 221 02-FGC 101 302 Uen C 2006-03-14

The IP Service Engine provides the functionality required to control the IP services on a session-by-session basis. It tracks the subscribers' service profiles and configures the underlying nodes to deliver those services at the establishment of a communication session.

Functionality provided by the IP Service Engine resides within two main categories:

• Session-level control of IP services

• Control of those services throughout their life cycle.

The operations occur between two layers:

• A business-oriented process top layer

• A network-oriented bottom with specific resource interfaces

The management and control functionality offered in IPSE's end-to-end solution refers to a configuration that includes the following components:

• Web Service Layer Interfaces

• Web Application Server

• Service Portals

• Service Fulfillment Engine

• Service Logic Controller (Policy Engine, Service Engine, PMT, RADIUS client, LDAP-compliant directory)

• OAM GUI to manage the SLC component.

• LDAP Server

• Resource Adaptors (Ras)

• Routers (ERX-series)

• RADIUS Server

• DNS and DHCP Servers

• SNMP Client/NMS


221 02-FGC 101 302 Uen C 2006-03-14 87

6 Standards and Interfaces The core of IPSE 2.0 offers a standard interface for easy integration to the surrounding business, operational and network management systems to create a complete and comprehensive service management solution. The solution is designed to simplify the integration with both internal and external systems. IPSE 2.0 is surrounded by the following interfaces:

IPSE 2.0

Web-Based GUI

Service Portal

Customer Care System

Network Management

SystemPolicy

Repository

User Profile Database

User Service Database

Resource Adaptor

RADIUS/AAA Server

Figure 18 IPSE 2.0 Standards and Interfaces

1 The LDAP v3 interface allows communications between the IPSE and the user, service and policy directories. In addition, this interface allows the IPSE Service Fulfillment Engine and the OAM/PMT to communicate with user, service and policy directories. LDAPv3 is used by the IPSE to dynamically look up profiles containing user and service information. The exact schemas of the external databases are handled by custom plug-ins within the IPSE.

2 The IPSE web-service interfaces are based on SOAPv1.1/HTTPv1.1 messages over TCP/IP. The Service Portal, Customer Care System, Service Fulfillment System and Web-based GUI all share the same application programming interfaces provided by IPSE.

3 The OSS/J service activation interface is based on v1.0 and allows CRM and/or OSS system to handle service subscription.


88 221 02-FGC 101 302 Uen C 2006-03-14

4 Any Network Management Systems can use the provided SNMPv3 to access the IPSE managed objects and their values.

5 The RADIUS interface allows communication between the IPSE and the AAA Server used for accounting and authentication.

6 Resource Adapters are part of the IPSE. They use an internal interface that is application-specific and is based on XML messages.

7 The proprietary APIs allow communication between IPSE and the routers.


221 02-FGC 101 302 Uen C 2006-03-14 89

7 Deployment IPSE 2.0 can be deployed according to the following four standard categories:

• Entry

• Small

• Medium

• Large

Each category comes with a predefined hardware and software configuration. However, IPSE can also accommodate customer-specific deployment requirements with the help of Ericsson professional services. It is possible to deploy the software differently and potentially on a different number of application servers.

Note: For detailed information on the supported hardware configuration, refer to the document entitled Ericsson IP Service Engine 2.0 System Requirement Description, 1/1555-APR 901 460/3

Table 3 shows the number of subscribers corresponding to their respective deployment types. This is a high-level approximation determined by the following predefined attributes, all which influence the runtime characteristics of IPSE 2.0:

• Number of subscribers

• Traffic model

• Number of services per subscriber

Table 3 – IPSE 2.0 Deployment Categories

Deployment type Description

Entry Up to 10,000 subscribers (Approx)

Small Up to 450,000 subscribers (Approx)

Medium Up to 750,000 subscribers (Approx)

Large Up to 1,250,000 subscribers (Approx)

Note: For detailed information on the dimensioning and the deployment of the IPSE 2.0, consult with your local Ericsson Support.


90 221 02-FGC 101 302 Uen C 2006-03-14


221 02-FGC 101 302 Uen C 2006-03-14 91

8 Benefits • Dynamic IP Service Control and Delivery is the mechanism for

providing differentiated services. This allows the operator to dynamically control the state of the service and to be able to deliver it quickly and in a profitable way. IPSE fulfills that need by having the ability to rapidly develop and deploy new services with dynamic control. This capability is a key factor for the successful deployment of profitable differentiated services.

• IPSE can interact with Broadband Remote Access Server (BRAS) devices and the Ericsson Ethernet DSL Access (EDA) in order to provide a comprehensive solution when introducing new, enhanced IP-based services. IPSE's open component-based architecture can be deployed in any Java 2 Enterprise Edition (J2EE) commercial platform.

• IPSE's unique layering allows for an open architecture that has plug-in Resource Adaptors that offer flexibility in incorporating interoperability with various network devices from multiple vendors.

• IPSE provides a policy-based framework for network management. Policies express the needs of the business and service-oriented upper layers that are dynamically binding to the IPSE.

• The IP Service Engine provides session management functions that allow the tracking of state-full dynamic transitions present during policy management.

• The IPSE's automated flow-through of data and operations allow services to be completely handled by the system from the point where a service is published to the end-user's consumption of the service.

• The IP Service Engine includes a Web Service Application Programming Interface (API) intended for business-oriented processes. The open interfaces allow for extensive use of the functionality in the IPSE by service portals, customer care systems, and other back-office systems.

• IPSE's service fulfillment system handles life cycle management, from service creation to the point of service delivery. A service planner can quickly create new services through the innovative and flexible service model.

• A BRAS controlled by IPSE can dynamically allocate IP interfaces to Virtual LANs (VLAN) in an access network. Dynamic allocation of IP interfaces to specific VLANs are required to create IP services with segregated bandwidth utilization. Hence, the network operator is able to have an expandable portfolio of revenue-generating IP services where each has its own level of quality.


92 221 02-FGC 101 302 Uen C 2006-03-14

• IPSE enables access operators to support both wholesale of the access services as well as retail sales of Internet access and content services. The multiple domain support provided by IPSE includes functionality for remote user authentication, service authorization, and accounting.

• IPSE allows automatic registrations of persistent users that are connected through the Ericsson EDA access network to an IPSE-controlled BRAS node (edge routers).

• IPSE’s short time to market for new services offers the possibility to quickly launch new services. It is possible to cost effectively trial new services with selected groups of subscribers, by quickly being able to alter parameters to optimize the service offering. Services templates can be created and modified without disrupting services to existing subscribers.


221 02-FGC 101 302 Uen C 2006-03-14 93

9 Summary IP Service Engine (IPSE) 2.0 is the solution for network operators who want to upgrade their network from a commodity bit-pipe to that of a high revenue-generating network that can offer a multitude of premium services for its discerning clientele. IPSE dynamically controls the network resources at the edge of the network for fixed-line broadband connections, providing a single management point interface for IP service information that is based on per subscriber, per session control. IPSE provides subscribers with a flexible broadband connection that lets them decide, through self-subscribing portal technology, the amount of bandwidth and the quality of service they want. With IP Service Engine, operators can own the service delivery process, reap new revenue providing premium services, and meet QoS, manageability, availability, and security needs.

IP Service Engine 2.0 supports rapid integration with existing and future Customer Resource Management (CRM) systems using the OSS-J standards-based orders. IPSE enhances order management with automated delivery that reduces the need for manual processes and controls escalating operation costs. A web-based Service Portal that can be incorporated into existing portals offers end users the possibility of a 24/7-service interface where they can subscribe to new services and modify subscriptions without the overhead of an extensive customer care network. A MIB is available for simple integration into existing Alarm and Notification systems. For Greenfield operators, a provisioning system with options for wholesaling portions of the network increases the potential for a faster Return on Investment.

IPSE’s architecture provides a flow-through of service and policy provisioning data between the end-users and service provider's back-office systems and network resources. The architecture allows operators to follow a standards-based mechanism that supports the Publication, Subscription, Initialization, and Registration of services. Operators can define interactions with new services using UML-based use cases and utilize Ericsson Professional Services to translate it into IPSE control mechanisms within weeks. This flexibility enables operators to rapidly drive a service offering from a commodity to that of a premium value.

The architecture lends itself to a multi-vendor, element-based network. All service functions are abstracted to policies, which IPSE translates to appropriate control mechanisms for specific network devices, through “Plug-in Resource Adaptors”. Past initial investments from network element suppliers are not compromised by new hardware acquisitions as IPSE allows operators to apply the defined policies to the new devices through Resource Adaptors. Operators can rest assured that a Resource Adaptor for the network element they are considering is either generally available or can be rapidly developed to meet an aggressive time to market.

Note: These Resource Adaptors are tested in the Ericsson labs for each version of the control interface of the supported network element. This is


94 221 02-FGC 101 302 Uen C 2006-03-14

an invaluable insurance policy for operators, as they can rely on having a stable network when upgrading the network control interfaces. IP Service Engine assures that the existing defined policies will work on the new versions without impacting the end user services.

The enriched services offered by operators embody QoS (Quality of Service). As operators upgrade their network elements to support the QoS standards (IETF Diffserv), IP Service Engine can ensure that QoS parameters are enforced by the network elements, thereby offering the end-user a consistent Quality of Experience.

IP Service Engine 2.0 affords operators an opportunity to lower CAPEX by over-provisioning the network based on its mix of enterprise and residential users. As users demand the service, the network resources are assigned.


221 02-FGC 101 302 Uen C 2006-03-14 95

10 Appendix

10.1 Juniper ERX Resource Adapter A specialized Resource Adapter (RA) has been developed to interoperate with the Juniper ERX-series routers. This Resource Adapter constitutes an integrated solution with the Juniper Service Activation Engine (SAE) product.

Keeping the IPSE Service Logic Controller and SAE as distinct and separate as possible is a design goal of the architecture of the complete Ericsson solution. Therefore, the option to operate the SAE in a stand-alone mode has been chosen. This flexible approach has the advantage of decoupling as much as possible the two software products.

The IPSE Service Logic Controller is not tightly constrained or dependent on the Juniper solution. This grants the IPSE a maximum of flexibility in integrating multiple network elements from other vendors.

The SAE runs as a separate process. In order to bridge the communication between the SAE and the Ericsson IPSE Service Logic Controller, the possibility to integrate a “hosted plug-in” within the SAE is exploited. The adaptation of the Juniper routers as a managed network resource within the IPSE follows a split architecture.

From the perspective of the IPSE, the Resource Adapter for Juniper ERX is divided into two modules:

• First Module executing within the IPSE Service Logic Controller

• Second module deployed as a plug-in in the SAE.

On the IPSE side, the Resource Adapter provides a generalized interface that includes the following outbound operations toward the Juniper hosted plug-in:

• Add policies

• Remove policies

• Start a session

• Stop a session

Inbound notifications from the Juniper plug-in to the IPSE Resource Adapter are:

• Login (authenticated or un-authenticated)

• Logout (authenticated or un-authenticated)

On the SAE side, the residing plug-in, customized for the IPSE needs, translates the interface methods bound to the IPSE into specific API invocations and constructs belonging to the Juniper software.


96 221 02-FGC 101 302 Uen C 2006-03-14

In the IPSE solution, the Java Messaging Service (JMS) is used as a transport for the content exchanged between IPSE Resource Adapter and SAE plug-in. This transport format is reliable because it provides persistent and acknowledgement mechanisms of the communicated messages in queues and destination groups. A high-level, yet simple, application-specific asynchronous protocol has been defined to direct the communication between Ericsson IPSE Resource Adapter (running in the Service Logic Controller) and the Juniper SAE plug-in.

The COPS protocol is used by the Juniper SAE to deploy and control policies in the ERX family of routers. It is, however, hidden to the Ericsson IPSE Service Logic Controller and Resource Adapter. The COPS protocol is used solely by the SAE to interact with the ERX routers. It is indirectly manipulated through the external invocations coming from the Resource Adapter to the hosted plug-in.

In the present decoupled configuration of the Ericsson IPSE and the specialized Juniper ERX Resource Adapter, many other possibilities are left open. Namely, to fulfill high-availability requirements, a number of redundant Juniper ERX routers can be managed by a cluster of SAE, which in turn are connected to many IPSEs. The Resource Adapter refers to the IP-address of a requested session as the distribution key to keep track of which Juniper SDX SAE and ERX router to control.

10.2 Cisco Resource Adapter Note: Due to some Cisco SSG software limitation, this Resource Adaptor is only offered for trials.

In version 2.0, a Resource Adapter is added to control Cisco routers that have the Service Selection Gateway (SSG). The Cisco SSG feature module is embedded in the hardware platform or the Cisco routers.

Cisco SSG communicates with external clients through the RADIUS to perform all functions: authentication, accounting, as well as policy provisioning.

Cisco uses the RADIUS protocol with Vendor Specific Attributes (VSA) to pass different commands. Between the Cisco Resource Adapter and the SSG, Access-Request/Accept and Accounting-Start/Stop messages are used bi-directionally to communicate the following:

• Login with authentication request (Access-Request toward the IPSE with redirection to an external RADIUS server. Acknowledgement is done with an Access-Accept/Refuse that is returned)

• Logout and stop-accounting (Accounting-Stop toward IPSE with redirection to RADIUS server)

• Activate/Deactivate services and add/remove policies respectively (Access-Request toward router)


221 02-FGC 101 302 Uen C 2006-03-14 97

• Start-Accounting (toward IPSE which redirects it to an external RADIUS server).

Note that the Cisco Resource Adapter is not notified of unauthenticated logins and logouts.

It is expected that for authentication, authorization, and accounting functions, Cisco routers must be configured to talk to the IPSE Resource Adapter. The latter acts as an agent and proxy, similarly to Cisco’s own SESM RDP (RADIUS Data Proxy)

The IPSE is compatible with Cisco’s Host-Key-bundle algorithm that is used to map an end-user session with the BRAS/edge router fulfilling the connectivity. The Host-Key of the BRAS/edge router is deducted from the source-IP-address and port of a managed end-user session.

10.2.1 Cisco Resource Adaptor Limitations

This appendix highlights Cisco’s Service Selection Gateway policy feature limitations. These shortcomings prevent IPSE to offer this Resource Adaptor as a commercially available optional feature.

Table 1 Cisco SSG Policy Feature Limitations

Policy Feature Comments

Per destination IP address or subnet conditions

Per source IP address or subnet conditions

Per from-port conditions

Per to-port conditions

Per distinguished IP flag(s) conditions

Per IP protocol conditions

For ICMP code and type conditions ICMP code is not supported by Cisco SSG

For IGMP type conditions

Per TCP connection flag(s) conditions Cisco SSG mapping to SYN, ACK, RST, URG, PSH and FIN

Packet marking by mask and value actions

Not supported by Cisco SSG


98 221 02-FGC 101 302 Uen C 2006-03-14

Packet next hop address actions Not supported by Cisco SSG

Packet next interface actions

Rate limit committed actions Cisco SSG only supports “drop” filter.

Burst limit actions

Rate limit committed marking actions Not supported by Cisco SSG

Rate limit conformed actions Cisco SSG only supports “drop” filter.

Rate limit conformed marking actions Not supported by Cisco SSG

Rate limit exceeded actions Cisco SSG only supports “drop” filter.

Rate limit exceeded marking actions Not supported by Cisco SSG

Peak Burst setting actions Not supported by Cisco SSG

Peak Rate setting actions Not supported by Cisco SSG

Traffic shaping for burst actions

Traffic shaping for rate actions


221 02-FGC 101 302 Uen C 2006-03-14 99

11 Terms and Acronyms

AAA Authentication, Authorization and Accounting

API Application Programming Interface

ASN.1 Abstract Syntax Notation One, used to specify data formats in the Mediator. ASN.1 is specified in X.208 from ITU-T

AVP Attribute Value Pair

BGw Billing Gateway

BRAS Broadband Remote Access Server

CDR Call Data/Detail Record

CLI Command Line Interface

COPS Common Open Policy Service protocol

CORBA Common Object Request Broker Architecture

DHCP Dynamic Host Configuration Protocol

DIAMETER IETF AAA protocol

DMTF Distributed Management Task Force

DNS Domain Name System

DSL Digital Subscriber Line

EDA Ethernet Digital Subscriber Line Access

ERX Broadband Edge Router by Juniper

FTP File Transfer Protocol. A standard mechanism (RFC 959) for transferring files between both UNIX and non-UNIX machines.

GPRS General Packet Radio System

GSN GPRS Support Node

GUI Graphical User Interface

HA High Availability

HTML Hyper Text Markup Language


100 221 02-FGC 101 302 Uen C 2006-03-14

HTTP Hyper Text Transport Protocol

IAB Internet Architecture Board

IAS Internet Access Server

IETF Internet Engineering Task Force

IMSI International Mobile Subscriber Identity

IN Intelligent Network

IP Internet Protocol

IPSE IP Service Engine

IP-sec Internet Security Protocol, a protocol improving the security for the IP protocol versions 4, and 6. IP-sec is integrated in Solaris 8 operating systems.

IRP Integration Reference Point

ISO The International Organization for Standardization is the major body responsible for the development of OSI standards; also used as a prefix to an International Standard number.

ISO code ISO coded data. International standardized interchange code where digits and characters are represented by the International Standards Organization Alphabet number 5 (IA5) character set.

ISP Internet Service Provider

ISP In Service Performance

L2TP Layer 2 Tunneling Protocol

LAN Local Area Network

LDAP Lightweight Directory Access Protocol

MIB Management Information Base

MPLS Multi-Protocol Label Switching, MPLS combines the strengths of Layer-3 routing and Layer-2 switching, to build high-performance IP networks. Layer-2 switching is positioned in the core of the network, where high concentrations of packet traffic mean that high-performance packet forwarding is required.

MSC Mobile services Switching Center

MSISDN Mobile Station Integrated Services Digital Network number


221 02-FGC 101 302 Uen C 2006-03-14 101

MVPN Mobile Virtual Private Network

NAS Network Access Server

NE Network Element, for example, a switch or a voice mail system.

NFS Network File System

OS Operating System

OSI Open System Interconnection is the evolving body of standards being developed by ISO for the interconnection of different computer systems within a network.

OSS Operations Support System

OSS/J OSS through JAVA Initiative

PCIM Policy Core Information Model

PDP Packet Data Protocol

PEM Public Ethernet manager

PPP Point-to-Point Protocol

PPPoE Point-to-Point Protocol over Ethernet

PPS PrePaid System, system for real time billing.

Process A program is an executable file on disk, and an executing instance of a program is called process. The Mediator application can be said to consist of several programs.

PVC Permanent Virtual Circuit

QoS Quality of Service

RA Resource Adapter

RADIUS AAA (Authentication, authorization and accounting) protocol running on UDP/IP according to RFC 2138/2865. Mediator has a RADIUS accounting server according to RFC 2139/2866.

RFC Request For Comments – proposed standard from the IETF.

RSVP Resources reSerVation Protocol

SCP Service Control Point

SMS-C Short Message Service Center

SNMP Simple Network Management Protocol


102 221 02-FGC 101 302 Uen C 2006-03-14

SNOS Service Network Operational System

SOAP Simple Object Access Protocol

SQL Structured Query Language

SSG Service Selection Gateway – Cisco BRAS type product

TCP Transmission Control Protocol

TFTP Trivial File Transfer Protocol. A standard mechanism (RFC 1350) for transferring files.

Thread A process can have several execution paths running concurrently. Each of these are said to execute in a thread.

TTM Time To Market

UDP User Datagram Protocol

UDR Usage Data Record

UMTS Universal Mobile Telephone System

VLAN Virtual Local Area Network

VOIP Voice Over IP

VPN Virtual Private Network

XML eXtensible Markup Language


221 02-FGC 101 302 Uen C 2006-03-14 103

12 References Ref 1 22101-FGC 101 237

Uen Rev. C Ericsson IP Service Engine 2.0 Commercial Product Description

Ref 2 RFC 2617 HTTP Authentication: Basic and Digest Access Authentication

Ref 3 RFC 2753 A Framework for Policy-based Admission Control

Ref 4 RFC 3064 Policy Core Information Model - Version 1 Specification

Ref 5 RFC 3198 Terminology for Policy-Based Management

Ref 6 RFC 3460 Policy Core Information Model Extensions

Ref 7 SNOS 1.0 ERA/LU/M-02:0051 Ref 8 OSS/J 1.0 OSS through JAVA Initiative

http://www.ossj.org/