Skip Headers
Oracle® Communications Service Broker Concepts Guide
Release 6.0

Part Number E23524-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

4 Service Broker Signaling Server Units

Oracle Communications Service Broker Signaling Server Units (SSUs) manage Service Broker connectivity to external networks. For each network domain, a specific implementation of SSU handles the network connectivity functions.

This chapter describes the purpose and functionality of each of the SSUs.

SS7 Signaling Server Units (TDM and SIGTRAN)

The Signaling System #7 (SS7) Signaling Server Unit (SSU) enables Service Broker to access legacy SS7 network entities (for example, MSC and SCP).

The SS7 SSU is the Service Broker connectivity point to the network Signaling Gateways (SGs) or Signaling Transfer Points (STPs). Serving as the Service Broker front-end o the SS7 network, the SS7 SSU provides Service Broker with a point code, presenting it to the network as an SS7 signaling entity. Service Broker IMs that require an interface to the SS7 network (for example, IM-SCF and IM-SSF), use the SS7 SSU to send and receive SS7 messages to and from the SS7 network.

While the SS7 SSU supports the SS7 SCCP and lower protocol layers, the Service Broker IMs that interact with the SS7 SSU handle TCAP and higher SS7 protocol layers (for example, CAP and INAP).

Towards the SS7 network, the SS7 SSU presents a possibly redundant logical interface (one or more point codes) that has redundant physical interfaces. Redundancy is accomplished by deploying the SSUs in pairs (1+1 architecture). The redundancy model for the SSU is Active/Active with no single point of failure.

The SSU's role is to process low SS7 stack layers (up to SCCP) and distribute the traffic to the Service Broker IMs for processing.

To facilitate access to an underlying SS7 stack, Service Broker wraps the SS7 stack in an SS7 process, which is available to the SSU through a TCP connection.

SS7 SSU is available for two types of SS7 network connectivity, described in the following sections:

SS7 SSU for Time-Division Multiplexing (TDM)

SS7 SSU over TDM provides Service Broker with connectivity to the legacy SS7 network over Time Division Multiplexing (TDM) physical infrastructure (i.e. PCMs) through the use of dedicated TDM signaling boards. Usually, SS7 SSUs are physically connected to STPs, but they can also be directly connected to MSCs, HLRs, etc.

Key Functionality

SS7 SSU over TDM supports the following key functionality:

  • Support for MTP1, MTP2, MTP3 and SCCP SS7 protocol layers, as shown in Figure 4-1.

    Figure 4-1 SS7 Protocol Stack Supported by SS7 SSU over TDM

    SS7 Protocol Stack Supported by SS7 SSU over TDM
  • Alias-based addressing: An alias is assigned to every SS7 network entity. Applications use Service Broker to interact with legacy SS7 network entities by specifying the alias of the destination entities. The SS7 SSU converts the alias to an SCCP address, that is used to route traffic in the SS7 network.

  • Global Titling (GT): Supports GT address format.

SS7 SSU for SIGTRAN MTP3 User Adaptation Layer (M3UA)

SS7 SSU over SIGTRAN M3UA provides Service Broker with connectivity to the legacy SS7 network over an IP-based physical infrastructure, using the MTP3 User Adaptation Layer (M3UA). SS7 SSUs are physically connected to an IP network through Signaling Gateways (SGs).

Key Functionality

SS7 SSU over SIGTRAN M3UA supports the following key functionality:

  • Support for IP, SCTP, M3UA and SCCP SS7 protocol layers.

  • Alias-based addressing: An alias is assigned to every SS7 network entity. Applications use Service Broker to interact with legacy SS7 network entities by specifying the alias of the destination entities. The SS7 SSU converts the alias to an SCCP address, that is used to route traffic in the SS7 network.

  • Global Titling (GT): Supports GT address format.

    Figure 4-2 shows an SS7 protocol stack supported by SSU over M3UA.

Figure 4-2 SS7 Protocol Stack Supported by SSU over M3UA

SS7 Protocol Stack Supported by SSU over M3UA

SIP Signaling Server Unit

The SIP Signaling Server Unit (SSU) is a SIP front-end for Service Broker that provides access to SIP-based networks (for example, IMS) and the various SIP/IMS network elements (for example, CSCF, AS). Every Service Broker IM that requires a SIP interface (i.e. IM-ASF SIP, R-IM-ASF SIP) uses the SIP SSU as a sole route to send/receive SIP messages.

Redundancy of the SIP SSU is accomplished by deploying the SSUs in pairs (1+1 architecture).

Key Functionality

The SIP SSU supports the following key functionality:

  • Alias-based addressing: An alias is assigned to every SIP network entity. Applications use Service Broker to interact with SIP network entities by specifying the alias of the destination entities. The SIP SSU converts the alias to an appropriate destination address that is used to route traffic in the SIP network. The same alias can be assigned to one or more SIP addresses, enabling alternative routing if one of the destinations is unreachable.

  • Heartbeat: The SIP SSU is actively checking SIP entities in the network using the SIP OPTIONS request to check their availability status. The status information is used when routing SIP traffic from Service Broker to the network.

  • Load balancing: When SIP traffic is designated to a certain address alias, the SIP SSU can divide traffic between more than one SIP address, providing load balancing between several SIP entities. Traffic is load balanced only between SIP entities that are known to be available, based on the heartbeat functionality.

Diameter Signaling Server Unit

The Diameter Signaling Server Unit (SSU) is a Diameter front-end for Service Broker, which provides access to remote Diameter entities (for example, OCS or HSS) in the IMS network. Every Service Broker IM that requires a Diameter interface, such as IM-OCF, uses the Diameter SSU as a sole route to send and receive Diameter messages.

Redundancy of the Diameter SSU is accomplished by deploying the SSUs in pairs (1+1 architecture).

Key Functionality

The Diameter SSU supports the following key functionality:

  • Diameter connectivity: The Diameter SSU communicates with peer Diameter entities, supporting incoming and outgoing traffic.

  • Alias-based addressing: An alias can be assigned to every Diameter network entity. Applications use Service Broker to interact with Diameter network entities by specifying the alias of the destination entities. The Diameter SSU converts the alias to an appropriate destination address that is used to route traffic in the network. The same alias can be assigned to multiple Diameter destinations to enable load sharing and alternative routing if a destination is unavailable.

  • Alias-based routing: You can assign one alias to different Diameter destinations. The Diameter SSU would distribute requests among all destinations, using a round robin routing mechanism. You can assign different aliases to destinations supporting different functionality, providing a way to route Diameter requests to a particular Diameter function.

  • Availability: The Diameter SSU holds a list of established Diameter transport connections and monitors their availability status when routing Diameter traffic from Service Broker to the network.

RADIUS Signaling Server Unit

The RADIUS Signaling Server Unit (SSU) is the RADIUS front-end for Service Broker that handles incoming RADIUS messages. Network entities transfer accounting messages to the RADIUS SSU, which then routes the messages to the appropriate IM, based on criteria defined for incoming messages. The RADIUS SSU is the sole route for transferring RADIUS accounting messages to the IM.

The RADIUS SSU also receives access messages containing subscriber authentication and authorization information. Access messages are then transferred to an appropriate Service Broker component.

Key Functionality

The RADIUS SSU supports the following key functionality:

Inbound routing: Messages are despatched to their destinations according to the local realm value of the User-Name AVP of the incoming message.

PCP Signaling Server Unit

The PCP Signaling Server Unit (PCP SSU) is a Portal Communications Protocol (PCP) front-end for Service Broker, providing communication with Oracle Communications Billing and Revenue Management (BRM) applications through PCP.

The PCP SSU receives charging requests from IMs, such as IM-OFCF PCP or IM-OCF PCP, and route the requests to BRM applications through the PCP.

Key Functionality

The PCP SSU supports the following key functionality:

  • PCP connectivity with Oracle Communications BRM applications: The PCP SSU routes PCP requests to BRM applications using connection pools that maintain secured connections with the Oracle Communications BRM Connection Managers (CMs).

  • A heartbeat mechanism: The PCP SSU implements a heartbeat mechanism, regularly sending requests to instances of BRM applications to check their availability. The PCP SSU stop sending requests to unavailable instance, but continues checking their availability every few seconds.

  • Alias-based routing: You can assign one alias to different instances of the same BRM application. The PCP SSU would distribute PCP requests among all instances, using a round robin routing mechanism. You can assign different aliases to instances of different BRM applications, providing a way to route PCP requests to a particular BRM application.

SMPP Signaling Server Unit

The SMPP SSU is a Signaling Server Unit (SSU) that enables Service Broker to communicate with Short Message System Centers (SMSC) through the Short Message Peer-to-Peer Protocol (SMPP).

In conjunction with IM-UIX-SMS and various network-facing IMs (for example, R-IM-ASF), the SMPP SSU enables Service Broker to act as an External Short Messaging Entity (ESME). As an ESME, Service Broker can send submit_sm messages to, and receive deliver_sm messages from, SMSCs.

Key Functionality

The SMPP SSU supports the following key functionality:

  • Routing a submit_sm message generated by IM-UIX-SMS to an SMSC. You can set up rules that define the SMSC to which the SMPP SSU sends the message.

  • Checking whether the SMSC is active using the heartbeat mechanism. Using this mechanism, the SMPP SSU sends regular requests to the SMSC and waits for a response. If the SMPP SSU does not receive a response within the specified period of time, the SMPP SSU considers the SMSC is inactive and does not send any further requests to this SMSC.

  • Routing a deliver_sm message that Service Broker receives from an SMSC to IM-UIX-SMS. You can set up rules that define the IM-UIX-SMS instance to which the SMPP SSU sends the message.

Web Services Signaling Server Unit

The Web Services SSU is an SSU that enables Service Broker to communicate with external entities using SOAP-based or REST-based communications.

Service Broker applications and other components (such as IM-WS) interact with external entities through the Web Services SSU.

The Service Broker applications that use the Web Services SSU include the IM-WS and the Top Up and Subscriber Store services, which expose SOAP APIs.

Key Functionality

The Web Services SSU supports the following key functionality:

  • Routing incoming requests to internal applications or IMs. A routing rule maps a requested resource (by URL) to an internal service or IM destination.

  • Acting as a client for external Web service providers used by Service Broker applications.

  • Applying authentication requirements to incoming requests. Service Broker can validate credentials in the form of HTTP Basic Authentication or WSSE UsernameToken credentials.