Before you start the installation process, it is important to understand the software topologies.
Diameter Enabler is deployed on the WebSphere® Application Server. Before beginning the installation you must have WebSphere Application Server Network Deployment version 7.0.0.7 or 6.1.0.29 installed on the server.
You can put the Rf accounting Web service, Ro online charging Web service, and Sh subscriber profile Web service in the same application server in a WebSphere Application Server installation. While the Rf, Ro, and Sh Web services reside on the same application server, each service will have a unique routing table.
Based on their configuration, the Rf accounting Web service, Ro online charging Web service, and Sh subscriber profile Web service can access entirely different Diameter server networks. They can also access the same Diameter server networks if those Diameter servers support Rf, Ro, and Sh interfaces.
RFC 3588 defines a maximum of one connection between any two Diameter peers. Therefore, if Rf, Ro, and Sh are used to access a peer, they must share a single connection. For shared connections, the connection configuration information must be identical in the Diameter_Rf.properties, Diameter_Ro.properties, and Diameter_Sh.properties files.
The Rf, Ro, and Sh Web services are configured to define the realms and connections to the Diameter network. You can specify different realms and connections for each of the Web services.
The IMS™ Application Server application is typically not installed on the same application server as the Rf accounting Web service, Ro online charging Web service, and Sh subscriber profile Web service. You must install the Rf, Ro, and Sh Web services on the same server as Diameter Enabler base.
An IMS Application Server can be installed in a different distributed environment. The Diameter interfaces are Web services and can be called remotely from any server.
Do not install Diameter Enabler on both a cluster and a single server instance that are running in the same physical computer.
Database support is not needed for the Rf accounting Web service and for most of the Sh and Ro Web services. However, a database is required to use the subscribe and notify capabilities of the Sh subscriber profile Web service. The database provides reliable retention of the active subscriptions and the endpoints to contact when the Home Subscriber Server (HSS) issues a notification that subscriber data has changed.
A database is also required when you use the Ro online charging Web service reauthorization request (RAR) notification. This is an unsolicited message sent from the online charging server to the Charging Trigger Function. If you do not require the subscribe and notify functions of the Sh and Ro Web services, no database is required.
If you require a database, the database should be remote from the server where the Diameter Enabler base and the Sh and/or Ro Web services reside before you create a clustered server.
If you require a database, you must install the database clients or provide the JDBC JAR files on all servers where Diameter Enabler is installed.
Diameter Enabler can interact directly with the Home Subscriber Server (HSS), the Online Charging System (OCS), or the Charging Collection Function (CCF) server. Alternatively, it can interact with Diameter agents–including proxies and relays. When there is a direct TCP connection between the Diameter Enabler and a Diameter server or Diameter agent, the server or agent is referred to as a Diameter peer or simply a peer.
Diameter Enabler can have exactly one connection to each Diameter peer.
The Rf accounting Web service provides an interface to the CCF, the Ro online charging Web service provides an interface to the OCS, and the Sh subscriber profile Web service provides an interface to the HSS. In most cases the CCF, OCS, and HSS will be on different physical servers.
Diameter Enabler converts a Web service request into one or more Diameter messages that it sends to the CCF, OCS, or HSS. Diameter Enabler also receives Diameter messages from the CCF, OCS, or HSS which it processes and returns to the applications on the IMS Application Server. The messages are returned through the Diameter Enabler Web services.
When Diameter Enabler sends a packet, it consults a routing table. The routing table is a simple structure based on the realm and Application Id that determines which connection to use when sending the packet. The route ties the final destination realm to the next hop connection for a given packet. Without a route in the routing table, the packet will not be forwarded even if a direct connection to the Diameter server is established.
Only one primary route to a destination realm can be configured within an environment (Rf, Ro, or Sh). A primary route is used to transmit Diameter packets whenever its underlying connection is active. Secondary routes are not required, but are recommended. A secondary route is used to transmit Diameter packets only when the primary route does not have an active or open connection. You can configure one or more secondary routes.
When the underlying connection of a primary route fails, the routing table automatically fails over to a secondary route where there is an active connection. If that connection fails and additional secondary routes are configured, the next secondary route is used until no more routes remain. If no primary or secondary routes are available, then a default route is used if one is defined. If no routes are available to carry the packet, an exception is sent to the user. If the primary route recovers from the failure, then all of the traffic is again routed through the primary route.
If no specific route is configured, you can configure a default route to forward packets. The algorithm selects a specific route first. If it is unable to find a match for the destination realm, it uses a default route. The default route can also be configured as a primary or secondary route.
The Rf accounting Web service, Ro online charging Web service, and Sh subscriber profile Web service have independent routing tables. Although all of these Web services use the Diameter Enabler base, the configuration and usage of the routing tables remain independent. Because of this, each Web service application can be started and stopped independently.
You must configure at least one realm, which can be either a specific realm or a default realm. Each Web service can support up to 10 realms. According to RFC 3588, you should have a primary and secondary route for each realm. The Diameter Enabler supports 10 realms for the Rf accounting Web service, 10 for the Ro online charging Web service, and 10 for the Sh subscriber profile Web service.
Therefore, you can configure 10 primary and 10 secondary routes for a total of 20 routes per Web service. If you are using all of the Web services (Rf, Ro, and Sh), then you can have a maximum of 60 routes total.