![]() ![]() ![]() ![]() ![]() ![]() |
The worlds of TCP/IP applications and of telephony networks continue to converge. Customers 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. Carriers want to be responsive to those desires, and to provide services that will satisfy customer 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 make it possible for a wider ranging development community to contribute. To do this, operators need to have a way to:
WebLogic Network Gatekeeper has been created specifically to help operators meet these challenges.
WebLogic Network Gatekeeper, built using version of WebLogic Server 10.0 MP01 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 network 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 Network Gatekeeper provides access to standard network capabilities such as SMS, MMS or Call Control through a set of easy-to-use Web Services-based interfaces tailored to their needs. These interfaces are largely based on well known standards, both Parlay X 2.1 and 3.0. In cases where access to desired functionality (WAP Push, Binary SMS, and Subscriber Profile) has not yet been incorporated into standardized forms, BEA has created Extended Web Services interfaces. All these interfaces are published in standard WSDL files, so service developers can use their choice of toolsets. Developers can focus on creating compelling and innovative services, while Network Gatekeeper uses its Communication Service components to do the heavy lifting of interacting with the various underlying network elements.
In addition to providing access to traditional telecom network functionality, Network Gatekeeper can also connect application services to SIP-based functionality, using WebLogic SIP Server. Calls set up using the Parlay X 2.1 Third Party Call communication service can be routed through SIP. Parlay X 2.1 Call Notifications can be established using SIP and Parlay X 2.1 Presence watchers (consumers of presence information) can be set up.
To assist application service developers, Network Gatekeeper can provide:
Network Gatekeeper always provides:
Managing a large number of services, particularly when the providers are third party partners, can be very 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, Network Gatekeeper can supply its Partner Relationship Management interfaces. These Web Service 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.
Network 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. Network Gatekeeper leverages the flexible security framework of WebLogic Server 10 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.
Network Gatekeeper’s powerful and responsive policy enforcement mechanism uses dynamically customizable 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 both Service Provider and particular Application accounts can be divided into groups to simplify SLA management and maintenance.
In addition, subscriber permissions and preferences can also 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 Network Gatekeeper itself, further Service Level Agreements explicitly define Service Provider access to underlying network nodes. In conditions of heavy load Network Gatekeeper employs throttling and shaping to protect the underlying network, prioritizing traffic based on these Network SLAs.
Network Gatekeeper provides an internal system for the routing of service requests directly to appropriate network nodes, based on address plans and actual destination addresses. Network Gatekeeper supports the as needed in production deployment of multiple instances of most network protocol plug-ins (the module that interacts most directly with the underlying nodes); routing can be managed on a very fine-grained and powerful way.
Based on WebLogic Server 10 MP01’s rock solid performance and superior clustering support, Network Gatekeeper’s architecture is designed to support the rigorous demands of telecom operators:
Network Gatekeeper is deployed in two tiers, which can be separated by a firewall for increased security. State is held only in the Network Tier, and each tier can be built out independently of the other
Network 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.
All traffic that passes through Network Gatekeeper is transactionally wrapped. Maintaining state consistently and durably in clustered and high performance environments is traditionally difficult, but Gatekeeper’s Storage Service uses a sophisticated strategy of optimizing storage strategies 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 as 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 around 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 Network 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 as desired.
Network Gatekeeper’s native charging mechanisms can also be integrated with an operator’s existing billing systems.
Using Network 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 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. This method 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 WebLogic Server 10.0 MP1 means that operators can both extend existing communication services to support new network interfaces, for example Unstructured Supplementary Service Data, and to create entirely new communication services to allow application service developers access to their network’s unique features, using Network Gatekeeper’s Platform Development Studio.
![]() ![]() ![]() |