What is OCSS7?
OCSS7 provides SS7 network connectivity to OpenCloud products, including the Rhino CGIN RA and the OpenCloud Scenario Simulator. It does this by implementing a set of SS7 and related SIGTRAN protocols. The current version supports M3UA, ITU-T SCCP, and ITU-T TCAP, and can act as an M3UA Application Server connected either to an M3UA Signalling Gateway or to another Application Server as an IP Server Process.
Main features
OCSS7 offers the following main features:
-
Provides IN network connectivity to OpenCloud’s CGIN and Scenario Simulator
-
SIGTRAN M3UA communication with Signalling Gateways and/or IPSP peers
-
Cluster deployment — SGC may be deployed in a cluster where multiple SGC instances cooperate and represent a single Signalling Point Code.
Supported specifications
Specification | Comment |
---|---|
RFC 4666 |
M3UA (ASP and IPSP functionality) |
ITU-T Q.711-Q.714 |
SCCP (excluding segmentation of LUDT) |
ITU-T Q.771-Q.774 |
TCAP (constrained to features supported by the TCAP SPI interface provided by the CGIN RA) |
More details on supported RFCs, see the OCSS7 Compliance Matrix.
Architecture
OCSS7 is composed of two main user-visible components:
-
the Signalling Gateway Client (SGC) TCAP Stack (frontend), automatically deployed as part of the Rhino CGIN RA, and
-
the SGC (backend), deployed as one or more separate processes.
After initialization, the TCAP Stack (frontend) registers with a preconfigured SSN at the SGC instance, and allows the CGIN RA to accept and initiate TCAP dialogs. Multiple TCAP Stack (frontend) instances representing the same SSN can be connected to the SGC instance (backend); in this case all incoming traffic will be load balanced among them.
The SGC provides IN connectivity for exactly one Point Code. Typically, the SGC is deployed as a cluster of at least two instances to meet standard carrier-grade, high-availability requirements. This manual primarily concerns itself with the OCSS7 SGC, as the TCAP stack component within CGIN RA is managed as part of CGIN.
Below is a high-level diagram followed by descriptions of the main components of the OCSS7 stack. The OCSS7 stack components are yellow. Components that are provided by the Rhino platform, CGIN, or the operating system environment are blue.
SGC Subsystems overview
All SGC nodes in the cluster represent a single logical system with a single PC (SS7 Point Code). Each SGC cluster node instantiates all stack layers and subsystems, which coordinate with each other to provide a single logical view of the cluster.
The major SS7 SGC subsystems are:
-
Configuration Subsystem — plays a central role in managing the life cycle of all processing objects in the SGC Stack. The Configuration Subsystem is distributed, so an object on any cluster node may be managed from every other cluster node. Configuration is exposed through a set of JMX MBeans which allow manipulation of the underlying configuration objects
-
TCAP Layer — manages routing and load balancing of TCAP messages to appropriate Rhino CGIN RAs (through registered TCAP Stacks)
-
SCCP Layer — responsible for routing SCCP messages, GT translation, and managing internal and external subsystem availability states
-
M3UA Layer — establishes and manages the SG, IPSP connectivity, and AS state.
Internally, all layers use Cluster Communication subsystems to distribute management state and configuration data, to provide a single logical view of the entire cluster. Irrespective of which cluster node receives or originates an SS7 message, that message is transported to the appropriate cluster node for processing (by the Rhino CGIN RA) or for further sending using one of the nodes' established SCTP associations.
SGC Deployment model
The SGC cluster physical deployment model is independent from Rhino cluster deployment. That is, SGC nodes can be deployed on separate hosts than Rhino nodes OR share the same machines.
See also
Installing the SGC
|
Management tools
The SGC installation package provides a CLI management console that exposes a set of CRUD commands that are used to configure the SGC cluster and observe its runtime state. SGC cluster configuration and runtime state can be managed from each and every node; there is no need to connect separately to each node. As the SGC exposes a standard Java JMX management interface, users are in no way constrained to provided tools and are free to create custom management clients to serve their particular needs.
The SGC also provides an SNMP agent, exposing SGC-gathered statistics and Alarm notifications (Traps) through the SNMP protocol.
The TCAP stack component installed as part of the Rhino CGIN RA is managed using the usual Rhino and CGIN RA management facilities.