|
|
The worlds of TCP/IP applications and of telephony networks continue to converge. Subscribers want services that provide them with functionality and flexibility that cross the traditional boundaries between the world of the Internet and the world of their phones. Operators want to be responsive to those desires, and to provide services that will satisfy subscriber demands, promote subscriber loyalty, increase average revenue per user (ARPU), and drive traffic to their networks.
But developing these services has historically been complex and ungainly. What is needed is a way to reduce the overhead of creating the applications that provide those services and to enable a wider ranging development community to contribute. To do this, operators need to have a way to:
Oracle Communications Services Gatekeeper has been created specifically to help operators meet these challenges.
Oracle Communications Services Gatekeeper, built using a version of Oracle WebLogic Server 10.3 ( http://download.oracle.com/docs/cd/E12840_01/wls/docs103/sitemap.html) that has been hardened and extended to support the specialized needs of telecom networks, offers a host of benefits for both application service developers and operators.
The protocols required by underlying telecom network capabilities are often complex, and the learning curve associated with achieving competence in using them is steep. To lower the barriers to entry for application service developers, out of the box Oracle Communications Services Gatekeeper provides access to standard network capabilities such as SMS, MMS or Call Control through a set of easy-to-use interfaces (called facades in Oracle Communications Services Gatekeeper). Depending on the desires of the operator, Oracle Communications Services Gatekeeper can offer SOAP style facades based on well-known standards such as Parlay X 2.1 and 3.0, RESTful style facades, and, in some cases, native protocol interfaces. SOAP style interfaces are also pre-integrated into an Oracle Service Bus environment, which offers application developers SOAP-based interfaces while allowing the operator the flexibility of SOA. In cases where access to desired functionality (WAP Push, Binary SMS, and Subscriber Profile) has not yet been incorporated into standardized forms, Oracle has created Extended Web Services interfaces. SOAP Web Services interfaces are published as standard WSDL files, so application service developers can use their choice of toolsets, while RESTful Web Services interfaces are designed for ease of use in pure HTTP environments. Developers can focus on creating compelling and innovative services, leaving the Communication Services components of Oracle Communications Services Gatekeeper to handle the mechanics of interacting with the various underlying network elements.
In addition to providing access to traditional telecom network functionality, Oracle Communications Services Gatekeeper can also connect application services to SIP-based functionality, using Oracle Communications Converged Application Server. Calls set up using the Parlay X 2.1 or RESTful Third Party Call communication services can be routed through SIP. Parlay X 2.1 or RESTful Call Notifications can be established using SIP and Parlay X 2.1 or RESTful Presence watchers (consumers of presence information) and presentities (providers of presence information) can be set up.
Oracle Communications Services Gatekeeper always provides:
To further assist application service developers, Oracle Communications Services Gatekeeper can optionally provide:
Managing a large number of services, particularly when the providers are third-party partners, can be time and effort intensive. As the market expands, with niche players and short-term services being added to the more mainstream mix, the logistics of on-boarding can become very complex. To assist operators in handling processes such as partner registration, service activation and provisioning, Oracle Communications Services Gatekeeper can supply its Partner Relationship Management interfaces. These Web Services interfaces can be used to support the automating of a wide range of partner-related tasks and to provide partners with easily available access to information about their accounts. The interfaces also allow operators to create groups of partners sharing sets of data, which can be used for tiering or segmentation of partners. Operators can then focus their administrative and partner management resources on their most rewarding partners.
Oracle Communications Services Gatekeeper can function as a single point of contact for access to the functionality of the underlying network, providing common authentication, authorization, and access control procedures for all applications, both internal and third-party based. For SOAP-based interfaces, Oracle Communications Services Gatekeeper leverages the flexible security framework of Oracle Web Logic Server 10.3 to provide robust system protection. Applications can be authenticated using plaintext or digest passwords, X.509 certificates, or SAML 1.0/1.1 tokens. Service requests can use XML encryption, based on the W3C standard, for either the whole request message or specific parts of it. And, to ensure message integrity, requests can be digitally signed, using the W3C XML digital signature standard. For RESTful interfaces, Oracle Communications Services Gatekeeper uses HTTP basic authentication: username/password and SSL.
Oracle Communications Services Gatekeeper’s powerful and responsive policy enforcement mechanism uses service level agreements (SLAs) to regulate service provider and application access to particular communication service functionality down to the level of supported operations and parameters. It also supports a range of quality-of-service guarantees that can be modulated by Time of Day/Day of Week, Rates, and Quotas. If desired, further rules covering access can also be added. And service provider and application accounts can be divided into groups to simplify SLA management and maintenance. Although Oracle Communications Services Gatekeeper ships with a set of broadly comprehensive SLAs, custom versions can also be created.
In addition, subscriber permissions and preferences can be reflected in a separate Subscriber SLA, created by the operator or an integrator using tools available in the Platform Development Studio. Subscribers can indicate, for example, that they wish to allow Service Provider X to query for the location of their mobile terminals, but not Service Provider Y.
In addition to the service level agreements that cover access to functionality within Oracle Communications Services Gatekeeper itself, further SLAs explicitly define service provider access to underlying network nodes. In conditions of heavy load Oracle Communications Services Gatekeeper employs throttling and shaping to protect the underlying network, prioritizing traffic based on these Node SLAs.
Oracle Communications Services Gatekeeper provides an internal system for the routing of service requests directly to appropriate network nodes, based on a variety of parameters, including sending application, destination address, or any arbitrary request parameter. Oracle Communications Services Gatekeeper supports in-production deployment of multiple instances of most network protocol plug-ins (the module that interacts most directly with the underlying nodes) on an as needed basis; as a result routing can be managed in a very fine-grained and powerful way.
Based on Oracle WebLogic Server 10.3’s rock solid performance and superior clustering support, Oracle Communications Services Gatekeeper’s architecture is designed to support the rigorous demands of telecom operators:
Oracle Communications Services Gatekeeper is deployed in two tiers, which can be separated by a firewall for increased security. State is held only in the network-facing tier, and each tier can be built out independently of the other.
Oracle Communications Services Gatekeeper is designed throughout to ensure multi-level protection against single points of failure.
To protect the system in the face of catastrophic failure, geographically distant sites can be set up as site pairs. Service Provider and Application Group SLA enforcement is synchronized across geographic sites and SLAs are enforced between the site pairs. Any changes in account configuration information are also replicated across sites.
All traffic that passes through Oracle Communications Services Gatekeeper is transactionally wrapped. Maintaining state consistently and durably in clustered and high performance environments is traditionally difficult, but Oracle Communications Services Gatekeeper’s Storage Service uses a sophisticated strategy of optimizing storage based on state access patterns. An in-memory store distributed among all the nodes serves as the entrance to data access. Reading from disk, and its attendant overhead, is reduced because the disk-based database functions as an archive rather than as a system of first use. This has two important benefits:
In addition, the Storage Service optimizes access to exactly the kinds of data that matter most in telecom traffic processing. Designed as a POJO java.util.Map-based API, client access is simplified for both storing data and making retrieval queries.
All or selected parts of the Oracle Communications Services Gatekeeper management mechanism can be integrated with an operator’s external Operation Support Systems through JMX/JMS or SNMP interfaces. The tasks associated with administering current service providers and adding new ones can be simply folded into existing systems.
Oracle Communications Services Gatekeeper’s internal charging mechanisms can also be integrated with an operator’s existing billing systems. Offline and online (using the Parlay X 3.0 Payment API) Diameter-based charging is supported.
Using Oracle Communications Services Gatekeeper, applications can customize their offerings by accessing subscriber profile information stored on network LDAP servers. At the same time, operators can protect subscriber privacy by using filters based on those same profiles to regulate the access that applications have, limiting the information that applications can acquire to what the subscriber wants to make available.
In addition, if they choose, operators can define a Subscriber SLA, which creates service provider groupings called service classes that can be associated with individual subscriber URIs. The mechanism to do this is created by the operator or integrator using the Profile Provider SPI provided as part of the Platform Development Studio. The use of a Subscriber SLA allows subscribers to customize their interactions with application service providers while keeping all their subscriber data within the confines of the operator’s domain.
A flexible architecture using the robust capabilities of Oracle WebLogic Server 10.3 means that operators can extend existing communication services to support new network interfaces, for example, Unstructured Supplementary Service Data. They can also create entirely new communication services to allow application service developers access to their network’s unique features, using Oracle Communications Services Gatekeeper’s Platform Development Studio.
|