| Oracle® Communications Service Broker Concepts Guide Release 5.0 Part Number E15180-01 |
|
|
View PDF |
| Oracle® Communications Service Broker Concepts Guide Release 5.0 Part Number E15180-01 |
|
|
View PDF |
The following sections describe Oracle Communications Service Broker components:
Service Broker offers control and orchestration of service delivery and realtime charging for each session, call, or event in the telecom network. It delivers solutions for telecom networks across multiple domains, covering SS7-based networks, SIP/IMS networks, Diameter-based charging platforms and interaction with web services. Service Broker provides two primary functions:
Mediation between applications (service logic) and different networks.
This function provides applications with access to switching and session control layers in different network domains (PSTN, PLMN, NGN,IMS), together with the required protocol.
For example, IN triggers from an MSC can be converted to a SIP session initiated towards an IMS application, opening a channel between the MSC and the IMS application, and allowing the application to respond and control the call routing in the MSC.
Orchestration of services.
This function enables the compilation of multiple applications for a single call or session. In addition, service orchestration enables IN applications to work together with SIP applications, enhancing service capabilities. In legacy networks, this function circumvents IN limitations that allow only one IN application to control a call or a session.
For example, a legacy prepaid service implemented by an SCP can be combined with a Follow-Me or VPN SIP-based application.
Service Broker is fully compliant with IMS and NGN standard methodologies of service interaction, charging and orchestration, including support for IMS and IN interaction and integration with Diameter for online/offline charging.
Figure 1-1 shows the position of Service Broker in the network.
From a service delivery perspective, Service Broker enables the delivery of the following services:
From legacy SCPs to new SIP/IMS clients
From SIP/IMS application servers to legacy domain subscribers
From a charging perspective, Service Broker enables the use of:
Diameter-based charging for legacy networks
Legacy charging platforms, such as Prepaid SCPs, towards data networks enabling Diameter (for example, GGSN Ro).
Service Broker allows a gradual and seamless migration path from legacy networks to an IMS domain and IT-based services. During the migration, Service Broker fully supports the continuity of services already available in the network, leveraging existing legacy infrastructure and installed base. Service Broker focuses on new investments in the IMS domain while capping investments in legacy equipment, creating a new offering to operators who can now evolve their network to SIP, mostly throughout the application layer.
Service Broker is based on an architectural design that allows the system to adapt to and interact with service platforms and session control entities in both legacy SS7 and IMS/SIP domains. Service Broker architecture is composed of the following components:
Orchestration Engine (OE)
The OE resides at the core of the Service Broker architecture. The OE routes service and charging requests from the network to one or more service platforms. The OE also manages interactions between service platforms and session routing across applications.
Interworking Modules (IMs)
A set of configurable and interchangeable modules that enable the OE to communicate with application platforms and session control entities in various network. Each IM provides interaction with a specific network element through the element's native protocol.
There are two types of IMs:
Network-facing IMs, which enable connectivity between Service Broker and session control entities, such as MSCs. Network-facing IMs provide a stateful front-end to session control entities so that they interact with Service Broker in the same manner they interact with application platforms, without the need to perform changes in configuration. IM-SCF, R-IM-ASF are examples of such modules.
Application-facing IMs, which enable connectivity between Service Broker and application platforms, such as IN SCPs, SIP ASs, IMS ASs, and Online charging servers. Application-facing IMs provide a stateful front-end to applications so that they interact with Service Broker in the same way they interact with the network, without the need to perform changes in configuration. IM-SSF, IM-OCF, IM-ASF are examples of such modules.
Supplementary Modules
SMs are configurable and interchangeable modules that facilitate and complement Service Broker solutions in certain deployments. SMs are provided with Service Broker and can optionally be used.
At the core of Service Broker, the interaction is normalized to a common session and event model. Each IM provides the conversion between the Service Broker internal representation of the session and the applicable external protocol. Through an extensive set of network and application-facing IMs, the OE extends service orchestration beyond IMS to pre-IMS, for example, IN, SS7 networks, and other non-IMS domains, such as SOA and IPTV. This enables orchestration and mediation between various application and charging platforms across different domains.
Figure 1-2 shows the full architecture of Service Broker with the Orchestration Engine at its core and with a complete set of Interworking Modules.
Service orchestration within the IMS domain is based on a concept of application assembly. This concept enables delivery of multiple services in a single session by routing the session through multiple applications. The chain of applications through which a session passes enables each application to accomplish its role in its turn.
The OE handles a session as follows:
The OE is triggered through Service Broker network-facing IMs by session control entities from both legacy and IMS domains.
IM-SCF enables triggering from a legacy domain, and R-IM-ASF and R-IM-OCF enable triggering from an IMS domain.
The OE routes the session to multiple applications through Service Broker application-facing IMs.
Interaction with applications is provided through the following:
IM-SSF towards IN SCPs
IM-OCF towards online charging servers
IM-ASF towards application servers
The route through multiple applications is not static, but is determined in real-time mode by orchestration logic, which the OE selects and downloads dynamically. (For more information on how the OE selects and obtains orchestration logic, see "Service Broker Service Orchestration".)
After the session passes the last application in the chain, the OE returns the session to the session control entity.
Figure 1-3 shows an example of how the OE routes a session.
Interworking Modules (IMs) are fundamental elements in Service Broker architecture that allow connectivity between Service Broker and the various service platforms and session control platforms in the network.
The IM-SSF implements the SSP part of the IN call state model and provides the interface between the IN SCP in the legacy network and Service Broker. From the SCP perspective, Service Broker acts as an MSC/SSP implementing the Service Switching Function, generating IN triggers, and interacting with the SCP.
IM-SSF modules are available for a variety of IN protocols and protocol variants including CAP, AIN, INAP, and WIN.
For example, the IM-SSF CAP supports the complete GSM SSF Call State Model allowing full CAMEL trigger interaction with any CAMEL SCP over CAP protocol.
The IM-SCF implements the SCP part of the IN call state model for each IN protocol and variant it handles and provides the interface between the MSC/SSP in the legacy network and Service Broker.
For example, the IM-SCF CAP supports the complete CAP Service Control Function (SCF) and IN state model, allowing interaction with any MSC using CAP protocol.
Acting as an SCP, it receives and arms IN triggers from an MSC/SSP and generates internal sessions to Service Broker, based on the trigger information.
IM-SCF modules are available for a variety of IN protocols including CAP, AIN, INAP and WIN.
The IM-OCF module implements the mediation module towards any external Diameter-based Online Charging Server, acting as 3GPP-compliant Charging Trigger Function (CTF).
Online Charging Server is a telecom platform providing online rating and charging, as well as subscriber balance management. IM-OCF is an application-facing module that interacts with online charging platforms using Diameter Ro, allowing real-time charging for any session, whether IN, SIP, or any other session or event that is mediated through Service Broker.
Deploying IM-OCF with Service Broker's IM-SCF provides a complete online charging solution for SS7-based networks using various IN protocols. Combining IM-OCF with Service Broker's R-IM-ASF provides a complete online charging solution for SIP-based networks, effectively acting as a 3GPP IMS Gateway Function (IMS-GWF).
The variety of protocols supported by Service Broker's IM-SCF allows IM-OCF to provide a real-time, online charging solution to CAP/INAP-based GSM/UMTS mobile networks, WIN/IS-826-based CDMA/1X/EVDO mobile networks and wireline AIN and INAP. It paves the way to a full prepaid/postpaid convergence for voice and data and the migration from legacy nodal Prepaid SCPs solutions to converged and unified charging.
Reverse IM-OCF (R-IM-OCF) is a network-facing IM. It provides an IMS Online Charging Function (OCF) frontend to the network. R-IM-OCF connects Service Broker with IMS core elements that implement 3GPP-compliant Charging Trigger Function (CTF), such as IMS-Gateway Function (IMS-GWF), using the Diameter Credit Control Application interface. It converts charging triggers for online rating and charging to an internal Service Broker representation.
Deploying R-IM-OCF with Service Broker's IM-SSF provides an online charging solution for IMS-based networks using legacy SS7 IN-based charging, that is SCPs. Deploying R-IM-OCF with Service Broker's IM-OCF provides an online charging solution for IMS-based networks that require mediation towards IMS OCFs. Therefore, R-IM-OCF allows real-time charging for IMS-based sessions using any charging function, whether IN or IMS.
R-IM-OCF allows Service Broker's OE to orchestrate real-time charging requests.
IM-ASF enables Service Broker to interact with IMS entities, that is applications and session control entities. It provides IMS entities with an IMS frontend to Service Broker. Typically, IM-ASF serves as an application-facing module that enables the delivery of a service to all session control entities. However, not all applications necessarily deliver services to all the entities.
IM-ASF is used in solutions where the application responds to sessions initiated by Service Broker. Applications that initiate new sessions interact through R-IM-ASF.
Reverse IM-ASF (R-IM-ASF) enables Service Broker to interact with IMS entities, that is applications and session control entities. It provides IMS entities with an IMS frontend to Service Broker. Typically, R-IM-ASF serves as a network-facing module, enabling Service Broker to be invoked by core IMS elements, such as S-CSCF, as well as other pre-IMS elements, such as Soft switches and MGCs. This allows IMS core elements to trigger applications that are connected to Service Broker.
IMS applications or session control entities that initiate new sessions interact through R-IM-ASF. In solutions where the application responds to sessions initiated by Service Broker, IM-ASF is used.
IM-PSX is a network-facing module that enables Service Broker to communicate between SIP applications and HLRs or VLRs in GSM and CDMA networks.
Integrating IM-PSX into Service Broker-based solutions enables SIP applications to:
Query a legacy network on information about subscribers, such as a subscriber's state, location, and the services a subscriber receives
Receive notifications from an HLR when a subscriber who was previously unaccessible 1254537 accessible again
Modify information about subscribers in a legacy network (in GSM networks only)
From the HLR's perspective, Service Broker acts as a standard entity in the same network. HLRs can communicate with Service Broker using the MAP protocol (in GSM networks) or ANSI-41 protocol (in CDMA networks). IM-PSX provides interfaces for both MAP and ANSI-41.
Supplementary Modules (SMs) are optional on-board modules, each facilitating Service Broker solutions in a different manner.
SM-Local Subscriber Server (LSS) is an implementation of a profile server that can be used as a source for service orchestration logic. LSS can store subscriber profiles, including orchestration logic defined in Initial Filter Criteria (iFC) format. When this supplementary module is deployed, the OE can retrieve orchestration logic from the LSS.
SM-Parameter Mapping Engine (PME) is a flexible XML-based engine that manipulates parameters in the headers and body of internal Service Broker SAL messages. SM-PME complements generic solutions with specific requirements and allows fine tuning of parameter mediation for standard and non-standard protocol parameters.
For example, SM-PME can manipulate XER representation of IN messages, allowing CAMEL Furnish Charging Information to update from one format to another Service Broker' OE can chain SM-PME at any point of the service orchestration in the same way that it chains Interworking Modules.
Signaling Server Unit (SSU) is a Service Broker component that enables Service Broker to connect to SS7-based networks and IMS-based networks through standard software and hardware interfaces. There is a specific SSU implementation to support connection to each network domain.
Service Broker includes the following SSUs:
SS7 SSU for TDM, which provides Service Broker with access to a legacy SS7 network through MTP protocols.
SS7 SSU for SIGTRAN, which provides Service Broker with access to a legacy SS7 network through M3UA protocols.
SIP SSU, which provides Service Broker with access to SIP-based networks.
Diameter SSU, which provides Service Broker with access to network entities that interact using the Diameter protocol.
For more information about SSUs, see "Service Broker Signaling Server Units".
The Service Broker deployment architecture is based on a separation into the following logical tiers as shown in Figure 1-11:
Signaling Tier
The Signaling Tier consists of pairs of servers on which SSUs run. Depending on specific requirements, each SSU—that is, SS7, SIP, and Diameter—can be deployed on a different pair of servers so that each SSU pair provides access to a different network. Alternatively, different SSUs—for example, SIP SSU and Diameter SSU—can run on the same server pair as shown on Figure 1-11.
The set of SSU deployments and servers is considered the Service Broker Signaling Tier. You can scale the Signaling Tier by adding pairs of Signaling Servers as required
Processing Tier
The Processing Tier is a set of servers on which Service Broker functional components run. These components include IMs, OE and SMs. The modules that run on the Processing Servers are stateful, where the state information is maintained and distributed across the Processing Tier.
The modules retrieve and store session state in an in-memory storage. On failure, functioning Processing Servers continue to retrieve and process all messages, including those stored in the in-memory state of the failed Processing Server. The Processing Tier of a Service Broker deployment includes two or more servers, employing an N+1 redundancy schema. Normally, at least two servers are deployed for redundancy purposes. Scaling the Processing Tier is possible by adding Processing Servers as required
The Signaling and Processing Tiers of the Service Broker make use of a modular OSGi (Open Services Gateway initiative)-based platform called the Axia platform. The Axia platform provides platform-level server services and a processing environment that:
Isolates individual processes and provides a container for managing those processes
Supports concurrent processing
Offers atomic and isolated execution of operations
Enables services to be transparently distributed to all Signaling Servers and Processing Servers in their respective domains
Provides redundancy and is scalable for high availability
Deploys Service Broker processing modules, such as IMs, OE and SSU components, within the Signaling or Processing Tiers
Both Signaling Tier servers and Processing Tier servers host platform-level server services.
For the purpose of modularization, the Axia platform is based on Oracle WebLogic Server and Equinox OSGi 3.5. Equinox OSGi is an Eclipse project that implements the OSGi framework. Service Broker components are packaged and deployed as OSGi bundles.
For more information about OSGi, see the OSGi Alliance Web site:
Server services offer functionality that is provided at the platform level. You configure certain server service functionality using the Administration Console or management scripts.
Server services include:
Deploying and managing the life cycle of Service Broker components. The deployment artifacts are OSGi bundles. You can perform a number of operations including installing, uninstalling, starting, stopping, and updating bundles.
Collecting, storing, and updating configuration data and propagating configuration data to Service Broker components across the domains.
Storing application-level data used by IMs and server services during runtime. This type of storage is provided as a memory store managed as an Oracle Coherence partitioned cache. The data in the cache is always replicated on at least two servers to ensure high availability.
Generating logs for each server in the domains. Logging is based on Log4J.
Generating notification messages for management and monitoring purposes, such as messages about the current state of a component or process, and warning and error messages.
Collecting traffic usage statistics. A usage statistic is a count of the number of events or messages that are sent and received. Usage statistics are generated, collected and stored for each server in a Signaling Domain.
Routing events to the appropriate Service Broker components.
Managing processing threads. Service Broker uses a number of work managers that share a pool of threads. The system automatically adjusts the thread pool to the work being scheduled in order to maintain as high a throughput as possible.
From a system administration perspective, Service Broker deployments are managed using domains. A Service Broker domain is a logically related group of servers. A Service Broker deployment includes two types of domains:
Signaling Domain—Used to manage the servers of the Signaling Tier and the SSUs executed on these servers. Servers in the signaling domain are named Signaling Servers.
Processing Domain—Used to manage the servers of the Processing Tier and the module instances (that is OE and IM instances) executed on these servers. Servers in the processing domain are named Processing Servers.
A Service Broker production deployment usually includes two domains, a processing domain and a signaling domain. Each domain is deployed as a set of at least two servers.
When the Signaling Tier provides connection to more than one network, as shown on Figure 1-11, different signaling domains manage each network connection. In this way, each signaling domain manages a pair of Signaling Servers and the SSUs running on these servers.
Note:
For testing and evaluation purposes, it is possible to deploy Service Broker with both the Signaling Tier and Processing Tier co-located on a single machine.The Signaling Domain and Processing Domain interact, and propagate protocol events across the tier boundaries.
The following sub-sections describe domain-related concepts and terminology, which are also shown in Figure 1-12.
Each server in the Processing and Signaling Tiers runs on its own Java Virtual Machine (JVM), and the term "server" reflects a JVM rather than a physical machine.
Servers can be added to and removed from the Processing Tier and Signaling Tier domains while the system is running, without service interruption.
Servers within a domain are symmetrical, which means that they all have the same Service Broker OSGi bundles installed and started.
Load balancers can be introduced between network nodes and Signaling Servers to distribute traffic between the network nodes and Service Broker.
A domain has an associated domain configuration, which is stored in a domain configuration directory. All servers in the domain have read-only access to the domain configuration directory. Each time a Processing Server or a Signaling Server is started, it retrieves configuration data from the domain configuration directory and then stores a read-only copy of the data for use during runtime. The domain configuration directory is accessed using a shared file system or via the Domain Configuration Web server.
The domain configuration directory stores also the Service Broker OSGi bundles.
The domain configuration directory is also accessed by the Administration Console, see "Administration Console".
The Administration Console enables you to manage a domain. Through the GUI, you can view the data stored in the domain configuration directory, and have read / write access to the domain configuration directory.
The Administration Console can be installed and run from any machine that has access to the domain configuration directory.
The Administration Console can run in two ways:
Standalone Administration Console
Web Administration Console
The Administration Console manages a single domain. In a typical production deployment there are two instances of the Administration Console, one to manage the signaling domain and another to manage the processing domain.
Note:
In a test environment, where one domain includes both Signaling Servers and Processing Servers, there is only one Administration Console instance. In this case, the Administration Console manages both the Signaling Tier and Processing Tier in one domain.Scalability is the ability of a system to provide throughput in proportion to, and limited only by, available hardware resources. A scalable system is one that can handle increasing numbers of requests without adversely affecting response time and throughput.
The growth of computational power within one operating environment is called vertical scaling. Horizontal scaling is leveraging multiple systems to work together on a common problem in parallel.
Service Broker scales both vertically and horizontally. Scaling options differ according to whether you are scaling the Processing Tier or the Signaling Tier.
The Processing Tier of a Service Broker deployment includes two or more servers, employing an N+1 high availability schema, where several Processing Servers are grouped together to share a workload. The Service Broker Processing Tier can increase its throughput by adding a new Processing Server to the processing domain. You can add a new Processing Server on either of the following:
A new physical machine (horizontal scaling)
A machine that already executes another Processing Server (vertical scaling)
In either way, all servers are grouped under one processing domain and administered from one instance of the Administration Console and in the same Domain Configuration Directory.
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
