HP VoIP solution for service providers     Introduction .....................2
                                           ...
Figure 1
Network architecture




                                        SMC                                             ...
• Complying with national regulations:                         • Applications interface:

                 – Calling-line ...
Figure 2
IP telephony network architecture




  Edge domain                              VoIP network                    ...
Figure 3
CCS distributed design




            Load distribution   Switching                   Switching unit            ...
Figure 4
OpenCall Service Controller Components Overview




                       Centralized management                ...
Figure 5
OpenCall SEP software architecture




           HP Service Managment Platform or User-developed applications


...
Figure 6
HP OpenCall SMP software architecture




        User-developed applications
         User-subscriber management...
Figure 8
Distributed Architecture




                       CCS softswitch               OCSC                           C...
Figure 9
Distributed Architecture hardware impact




           Mono CCS softswitch solution

           Core solution   ...
Figure 10
OCSC Distributed Configuration




   Distributed SEPs per application zone                             Distribu...
Figure 11
SMC interface with PSTN networks




                N+1 architecture based on DS10/TS10                        ...
Figure 12
Call failure using “light” Class IV



               Originating                   Direct Mode                 ...
Figure 13
Rerouted call using “true” class IV



            Originating                CCS                         OCSC  ...
Access domain                                                  IP Media Server
               The Access domain is compose...
Endpoints                                                     Conclusion
              The HP solution supports multiple e...
Figure A-1
CCS logical diagram




               Q.1224 with           IN Services            Provisioning          Super...
Figure A-2
CCS O-BCSM and T-BCSM




 Originating—basic call state machine                                                ...
Figure A-4                                                                        Figure A-5
Scenario 1—basic call        ...
HP VoIP solution for service providers
Upcoming SlideShare
Loading in...5
×

HP VoIP solution for service providers

1,164

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,164
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
30
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

HP VoIP solution for service providers

  1. 1. HP VoIP solution for service providers Introduction .....................2 Target voice......................4 VoIP networks ...................4 white paper OCSC components ...........6 Deployment in operation....9 Edge domain .................12 Core Class IV domain .....13 Class V domain ..............14 Conclusion .....................16 Appendix.......................17 Network and Service Provider Solutions
  2. 2. Figure 1 Network architecture SMC Teleworker Home office SS7 network CCS OCSC ISUP H323 SS7 SIP Small office MGCP VoIP network Access network Call center H248 PSTN Media gateway Large office PLMN Trunk RTP IP media server OSS-BSS Optional Interconnect Introduction The scope of the document is to provide service providers with technical information on the network architecture. This document describes the solution that HP, through a successful partnership with NetCentrex, offers for the Requirements and long-term architecture deployment of telephony services over a broadband net- Implementing and deploying a complete VoIP network work using Internet Protocol (IP) technology. generally requires the following actions. The components of the solution are • Building the core infrastructure: • CCS (Call Control Server) softswitch—performs – Enable voice on the IP infrastructure by deploying advanced Call Control and Switching functions and pro- voice-enabled gateways, ensuring voice quality and vides enhanced Voice over IP (VoIP) revenue-generating security services – Interface to the PSTN (Public Switched Telephone Net- • OCSC (OpenCall Service Controller)—allows the intro- work) or partner VoIP networks at various locations; duction of value-added services on top of the softswitch. each PSTN location may have its own signaling flavor, OCSC serves as a central point for service deployment and VoIP networks provide fewer standardization and hosts the central repository and the service issues but more security risks provisioning – Decide on a hierarchical routing plan and numbering • SMC (Signaling and Media Controller)—interconnects convention inside the network the existing Public Network (i.e., PSTN) and the VoIP – Predefine automatic recovery call flows to resist network at a Call Control–Signaling level and controls a internal network failures set of Media Gateways responsible for the interconnec- tion at a media and voice trunk level – Predefine call rerouting rules to recover from call completion failures in the PSTN or other partner’s Optionally HP IP Media Server can be offered to perform networks IVR (interactive voice response) or IP voice mail functionalities. – Decide on a disaster recovery strategy – link the network accounting records to a rating and billing engine, in batch mode or real time, and devel- op recovery strategies in case the billing system fails – Comply with the legal requirements that have an impact at the infrastructure level, such as ensuring caller ID is managed properly and Local Number Portability (LNP) has an impact on the routing plans – Provide network announcements 2
  3. 3. • Complying with national regulations: • Applications interface: – Calling-line identification restriction – Class V softswitches for residential telephony applica- – Malicious call identification tions or Centrex – Legal interception – Applications for the corporate market, such as network – Carrier selection Interactive Voice Response (IVR) units (Voice Extensible – Local Number Portability Markup Language [Voice XML]), Virtual Call Centers in the network, voice VPN, and videoconferencing – Emergency services (i.e., 911 in the US; 112 in Europe) – Third-party application service providers The scope of the document is to provide • VoIP solution management: – Integrate VoIP components in the existing OSS and service providers with technical information BSS or provide standalone network operation capabil- on the network architecture. ities: FCAPS, billing – Enable user access and control to some data (i.e., self- provisioning of user profiles) In order to ensure unlimited scalability and to cover any geographic region, the functions listed above need to be distributed over several servers in the network. This also • Class IV services: allows the service provider to delegate regional network – On-net–to–On-net calls (calls originate and terminate management to several regional administrators. on the IP voice network) – On-net–to–Off-net calls (calls originate on the IP voice network and terminate on PSTN) – Off-net–to–On-net calls (calls originate on PSTN and terminate on the IP voice network) – Management of dial plans (inter-area code, international, and inter-carrier) – Call routing, load balancing, and fault recovery – Network announcements • Residential Class V services: – Call Forward on Busy – Call Forward on No Answer – Call Forward Unconditional – Call Hold – Call Waiting – CLIP (Calling Line Identification Presentation) – Code Restriction services – Denied Origination – Denied Termination – Feature activation – Find Me and Follow Me services – Three-way calling 3
  4. 4. Figure 2 IP telephony network architecture Edge domain VoIP network Provisioning Class IV domain LNP, VPN, LCR Emergency services IP Centrex services Supervision Sigtran CCS Interconnect • Residential gateways SMC (MGCP, H.323, SIP) Accounting • IP phones and soft OCSC Billing OSS/BSS phones (MGCP, H.323, SIP) • IP PBXs Self-provisioning • VoIP PDA Prepay HTML • Mobile 2G, 2.5G 800 • POTS CCS LDAP VPN • PBXs Converged network Class V domain media server SCP AIN, WIN, IN Access domain Access domain HTTP server Registrar Access GK Target voice architecture An IN approach to VoIP networks The target network is built on a layered architecture, When services are deployed within a legacy telephony including: network, they can take advantage of the network architec- ture. The latter is typically an Intelligent Network (IN) • An edge domain—responsible for peering relationships architecture in which there are basically two ways of with all third-party networks, including PSTN and other implementing services: VoIP networks that may be used to terminate calls • A network service platform called the “Service Node.” • A core Class IV domain—responsible for routing calls This element has a few interactions with the rest of the between all other domains and Local Number Portabi- IN. The IN routes the call to the Service Node, which lity (LNP) and emergency calls, as required takes the call, processes it, and typically issues an out- • A set of application domains—responsible for more bound call to the final call destination. The service is advanced features, such as Class V call control completely hosted by the Service Node. • A set of access domains—responsible for the direct • A kind of “Service Logic” of the Service Control Point management of Customer Provided Equipment (CPE), (SCP). This service is hosted partly by the SCP and part- including IP address and alias registrations; this domain ly by equipment called the “Intelligent Peripheral,” which is most useful in the context of a Class V telephony serv- is mainly in charge of voice processing. ice and is not needed for other, simpler services, such Both options have their assets and drawbacks. They illus- as voice VPNs trate how regular telephony networks provide frameworks The core product of the network is the CCS VoIP softswitch for deploying value-added services. as illustrated in figure 2 above. The world of IP telephony is on the move and is described by protocols H.323, SIP (Session Initiation Protocol), MGCP (Media Gateway Control Protocol), upcoming Megaco (Media Gateway Control), and so on, but there is no architecture on top to implement services, since they exist in the PSTN world. It would be highly valuable to take all the assets of IN architecture and combine them with the openness, flexi- bility and mobility features of the IP world. This is the objective with the proposed architecture and its combina- tion of the CCS and OCSC (OpenCall Service Controller) products—to provide the VoIP networks with a true, carrier-grade call-control architecture, making it possible to implement value-added services. 4
  5. 5. Figure 3 CCS distributed design Load distribution Switching Switching unit Accounting Media services Switching unit Accounting System SVI Switching unit master unit master unit Switching unit Accounting master unit Switching unit IP network LAN/WAN Protocol translation Access Subscriber IN services System unit access unit Shared master registered Subscriber Application unit Protocol database access unit server translation Shared unit registered Subscriber Third-party database access unit SCP Without going into too much detail about CCS and CCS components OCSC, the following comparisons can be made: CCS can support multiple VoIP protocols, mediate between VoIP protocols, and enable protocol-agnostic applications • Call Control Server (CCS), which is composed of an that leverage the ITU standard Intelligent Network triggers. H.323v2 gatekeeper, and a SIP Proxy Server, to which an Intelligent Network state machine is implemented The CCS softswitch (Q.1224), carry out the equivalent of the Service • Is scalable to system demands and has the capacity to Switching Function (SSF). support a linear increase in simultaneous calls and calls per second by adding Switching Units (SUs) • The equivalent of the Service Control Function (SCF) is carried out by OpenCall Service Controller (OCSC), • Supports all the carrier-class redundancy and fault- which services the creation environment (call handling, tolerance features required by service providers media, contact centers, and so on). System Master Unit CCS has Detection Points (DPs), which makes it possible The System Master Unit (SMU) is instrumental in achieving to trigger specific processing events during the different true carrier-class reliability and fault tolerance. All calls steps of a call (connecting, busy, no answer, and so on) are directed to the SMU and then distributed to available or upon the reception of H.323- and SIP-specific events. CCS Switching Units (SUs). Each SMU centralizes the Services running on OCSC control the CCS Detection SNMP capabilities, makes sophisticated call-load distribu- Points by activating and deactivating specific events either tion algorithms available to the SUs, and performs statically or dynamically during the progression of a call. proactive SU monitoring to ensure uninterrupted call com- pletion. Automatic failover to a backup SMU assures Thanks to the OCSC and CCS interface, services are seamless carrier-class, fault-tolerant operation. capable of controlling and modifying the IP telephony sig- naling “on the fly,” making it possible to implement a Switching Unit number of advanced features. The CCS Softswitch Switching Unit (SU) handles core call control and switching technology. The Intelligent CCS capabilities are critical since they implement call- Network (IN)–based design enables the creation of VoIP- switching functions, as well as sort and sequence the call independent services that use an IN-state machine and progression phases. Q.1224 triggers. Thus, both the core softswitch services With this carrier-grade VoIP architecture implementing an and applications are available to all supported VoIP IN call model and providing Class IV and Class V capa- protocols (H.323, SIP, MGCP), depending on selected bilities, it’s possible to achieve a “happy marriage” by protocol options, endpoints, and networks. combining the best of the Intelligent Network philosophy The SU also includes a comprehensive Class IV call rout- with the best of the IP world. ing engine, configurable through a telnet interface. The routing engine enables a two-level dial plan translation: • From the source format to the “pivot” format, which will be used by the accounting system • From the “pivot” format to the destination format 5
  6. 6. Figure 4 OpenCall Service Controller Components Overview Centralized management Service Execution Platform (SEP) • Available in simplex and duplex configuration; cluster configuration planned for 2003 • Real-time execution of centralized services SCE SMP • Multinetwork and multivendor connectivity Data WAN Service Managment Platform (SMP) • Central data repository with down Distributed application processing and up propagation to the SEP • Available in simplex, duplex, or cluster configuration • Oracle9i with RAC option Service Creation Environment (SCE) SEP SEP SEP • Graphic state machine edition • Creating data base structure SS7 IP • Compiling message sets In addition, the SU also provides integration with Open- Value-added services can be implemented in two Call Service Controller. non-exclusive ways: In small trial deployment, the SU also includes the Subscriber 1. In the Media Server—using the Service Creation Envi- Policy Engine, which implements the IETF (Internet Engineer- ronment (SCE) that makes it easy to implement and ing Task Force) Call Processing Language (CPL). operate Media Services, thanks to a completely graphic environment Shared Registration Database Unit The Shared Registration Database (SRD) Unit handles CPE 2. In an Intelligent Network—triggering Service Logic by registration by storing all registered endpoints in a memory- specific CCS detection points; the Service Logic is resident database. Automatic failover to a backup SRD located on a third-party SCP and may involve media ensures seamless carrier-class, fault-tolerant operation. The resources that act as a VoIP Intelligent Peripheral, fea- SRD is used only for limited deployments. For large-scale turing INAP CS1, CAMEL, and WIN-IS41 protocols deployments, a distributed architecture with an external access domain, as described above, is recommended. OCSC components Subscriber Access Unit As shown in figure 4 above, the HP OpenCall Service The Subscriber Access Unit (SAU) provides multiline fea- Controller is composed of three components: tures (i.e., call hold, three-way conferencing, and so on) to residential gateways or IP phones that use the Media 1. OpenCall SEP—Service Execution Platform Gateway Control Protocol (MGCP). While H.323 or SIP 2. OpenCall SMP—Service Management Platform endpoints handle multiline features internally, MGCP/L endpoints are much simpler and require the use of SAU, 3. OpenCall SCE—Service Creation Platform (optional) which provides the following features to MGCP/L HP OpenCall SEP endpoints: call hold, call retrieve, call transfer, call wait- OpenCall Service Execution Platform (SEP) provides the ing, dial tone, call return, last number redial, call hold capability to introduce, execute, control, and manage voice prompt, and three-way conferencing. The SAU can customer-built services quickly, efficiently, and economical- be used in residential services, as well as IP Centrex ly within the converging telephony and IP networks. The offerings, to provide class V multiline features. SEP is an environment for running service applications Note: The Accounting Master Unit is not used in this and an in-memory database, providing real-time access architecture since CDRs (call data records) are being to the customer information used by the services. The SEP generated by OCSC (OpenCall) and not by CCS. architecture is based on active and standby mechanisms. The active SEP handles all the calls, and when it fails, the standby SEP is activated. 6
  7. 7. Figure 5 OpenCall SEP software architecture HP Service Managment Platform or User-developed applications Platform management applications Database API Service Provisioning API Node Management API Real-time memory Real-time and safe Telecom management Events, alarms database service logic execution information base environment Message set customization INAP/TCAP SS7 IP Fault tolerance controller HP/UX The OpenCall SEP serves as a central point for service • For High Availability (HA) of the platform, the SEP execution and is invoked systematically by the CCS transaction processing components are duplicated. SEP through an API (Application Programming Interface) contains a high-performance, in-memory relational whenever a call is presented to the softswitch. database for storing subscriber and service-related infor- mation. The information can be read and updated by The services running on SEP are responsible for call rout- the services running on SEP. The database is replicated ing within the VoIP network, management of numbering in the HA SEP configuration. plans, and CDR generation. The database is optimized for real-time read/write access, OpenCall SEP software components including writes replicated to the standby processor for the OpenCall SEP software includes the following HA configuration. The database consists of a series of components: linked tables that can be freely defined by the Service • Service Logic Execution Environment (SLEE)—provides Designer. It is possible to configure which data is local to the execution environment for Service Logic Programs the active processor, which data is replicated to the stand- (SLPs). The SLEE also incorporates the SEP database by processor, and which data is replicated to the optional and associated management functions. SLEE provides Service Management Platform (SMP), if applicable. Appli- the environment and resources to the run advanced call- cations running in SLEE have complete access to the routing functions necessary for VPN-IP Centrex services. database for read, write, navigate, and other operations. • Fault Tolerance Controller (FTC)—monitors and controls SMP accesses the SEP database through a published the duplicated processes running on each platform host management API. For the HA configuration, the database and controls automatic switchover in the active SLEE is replicated in the standby SLEE. The associated files on disk in the active SEP host are also • Event Handler—controls the display and logging of mes- replicated on disk in the standby SEP host. sages and alarms SEP–replicated hardware • The CCS-Proxy–implementing INAP over IP—controls In an HA SEP, the hardware consists of two computers, and manages the communication with the CCS active and standby, which are connected by a duplicated Softswitch LAN. The standby computer is a hardware replicate of the active computer. For CCS softswitch connectivity, each host OpenCall SEP transaction processing components contains two dedicated LAN cards, ready to take over. perform the following actions: • The SEP real-time database stores service information used by the services. 7
  8. 8. Figure 6 HP OpenCall SMP software architecture User-developed applications User-subscriber management applications User service provisioning applications SCE Schema SQL API SMP node management generation Industry-standard Oracle database for service and subscriber data Real-time update Audit and Statistics collection propagation resynchronization Down Up confirmed HP/UX HP MC/ServiceGuard Single or multiple distrubuted HP service execution platforms Database API Service provisioning API Node management API In normal mode, the active system controls all network Figure 7 HP OpenCall service logic creation connections. The standby system takes control of all con- nections during a failure of any critical hardware or software in the active system. This process is called switchover, where the standby system becomes the new active system and is ready to process network messages. HP OpenCall Service Controller SMP The HP OpenCall Service Controller Service Management Platform (OCSC SMP) can synchronize and manage sub- scriber data through an industry-standard SQL interface and an Oracle® Relational Database Management System. This is achieved even among geographically dis- tributed OCSC SEPs, CCSs, and SAUs. Centralized SMP enables customer care applications to access and utilize a rich set of subscriber information more easily and cost-effectively, supporting the development of differentiated customer care services. OCSC SMP provides a central repository for network topology, service, and customer data, serving as a focal point for service deployment and data management across the network. The SMP is built around an Oracle database, providing open access to service and customer data through multilevel APIs (e.g., Java™ data access objects and Oracle stored procedures). The HP OCSC platform provides sophisticated propaga- HP OCSC SCE tion mechanisms between the SMP Oracle database and HP OpenCall provides a powerful Service Creation Envi- the SEP real-time database, allowing instant and seamless ronment (SCE) for future service expansions and service availability of provisioned data to the service. As soon as customization with a GUI-based environment that automat- the provisioning manager submits updates, service config- ically generates state machines and execution code that uration changes are taken into account by the service. will be running in the SEP with the real-time database. HP OCSC also stores CDRs before their collection by reporting and billing systems. 8
  9. 9. Figure 8 Distributed Architecture CCS softswitch OCSC CCS softswitch 150,000 users Application zone 1 150,000 users Application zone 2 backup Call control zone 1 Call control zone 2 Call control zone 2 backup Call control zone 1 backup CCS-based routing or Standard LRQ Inter-softswitch call flow CCS softswitch OCSC CCS softswitch 150,000 users Application zone 2 150,000 users Application zone 1 backup Call control zone 3 Call control zone 4 Call control zone 4 backup Call control zone 3 backup Deployment in operation Management Platform. To move from a simplex to duplex configuration, thus making OCSC high availability, High availability requires: When going into operation, it is critical for any telecom- • One additional SEP server munications company to have a High Availability (HA) telephony system in order to provide the carrier-grade • One additional SMP server (optional) level of service that these clients expect. High availability can only be deployed on the SEP, which is With the High Availability option: the real-time service engine, while SMP remains in simplex. For a full HA, both platforms require an additional server. • There is no single point of failure in the system. • It becomes possible to modify system hardware and soft- Disaster recovery ware without stopping operations. A network of CCS softswitches and OCSC application servers can resist the complete destruction of a given • Network wiring and connectivity is fully redundant (also system (or complete network isolation of a given system)— requires redundant routers in the service provider i.e., a CCS, an OCSC, or both. Each edge device needs network, using HSRP [Hot Standby Routing Protocol] or to be configured with a primary and backup CCS a similar health-check real-time protocol, and appropri- softswitch, and the routing tables of CCS softswitches in ate routing protocols). the network need to have two routes or more defined for each destination. Similarly, each CCS softswitch needs CCS high availability to be configured with a primary and backup OCSC The CCS platform features an N+1 redundant policy. application server. Making CCS high availability requires: Call processing capacity increase • One additional SMU There are two models for scaling a software-based function. • One additional SU • Operating system–based multiprocessor scaling— • One additional SRD (optional—trial configuration) writing the code in a multithreaded form allows the operating system to use multiple processors to increase • One additional SAU (optional—residential or IP system capacity. This approach works well for medium- Centrex) scale configurations, but its cost increases exponentially • One additional server for the Media Server (optional) with the number of processors, as the additional processing power made available to the application for OCSC high availability each new processor decreases steadily with the number The OCSC features an active/standby redundant policy of processors already in place. There are also some for both the Service Execution Platform and the Service operating systems with this approach. 9
  10. 10. Figure 9 Distributed Architecture hardware impact Mono CCS softswitch solution Core solution Accounting Supervision Provisioning self-care CDR’s SNMP HTTP SPE OC service controller Voice mail CCS softswitch Access domain SS7 Access zone AGK SMC PSTN H.323 CPEs Mono CCS softswitch solution Core solution Accounting Supervision Provisioning self-care CDR’s SNMP HTTP OC service controller H.323 CCS based routing H.323 SPE or SPE CCS Softswitch CCS Softswitch standard LRQ inter-softswitch call flow Voice mail Voice mail H.323 SS7 SS7 H.323 Access zone AGK SMC PSTN SMC Access zone AGK H.323 CPEs H.323 CPEs • Distributed programming—this is the approach used (network announcement servers and “simplified voice by the CCS softswitch. The CCS code is not only multi- mail” for which the required capacity is a function of the threaded but also distributed on several physical number of total calls likely to be handled by the system— machines, each with its own operating system. The sys- 1 to 10 typically) to reach the maximum call processing tem is linearly scalable, i.e., each additional machine capacity of 15,000 calls (the maximum per CCS) allows the system to gain a fixed capacity, regardless 2. Increasing the capacity beyond 15,000 calls and/or of the number of systems already in place. taking into account geographic constraints (see the A single CCS configuration can grow by adding switching “Distributed Architecture” discussion below) units to an aggregate capacity of 1.8 million Busy Hour The solution architecture presented describes a centralized Call Attempts (BHCAs) and 15,000 simultaneous calls. system using only a single softswitch and application Call processing capacity increase means two things: server resource. This solution has some limitations and drawbacks that can be solved by using a distributed 1. Increasing the capacity of the CCS, which means architecture using multiple CCS softswitches and OCSC increasing the number of SUs (Switching Units) and the application servers. number of corresponding servers for the Media Server 10
  11. 11. Figure 10 OCSC Distributed Configuration Distributed SEPs per application zone Distributed SEPs in mated pair CDRs CDRs OCSC Accounting OCSC Accounting Service management SNMP Supervision Service management SNMP Supervision platform platform Provisioning self-care Provisioning self-care HTTP HTTP Application Application Application zone 1 zone 2 zone Service Service Service Service execution execution execution execution platform platform platform platform Distributed Architecture When adding a new zone to a VoIP telephony network, Using Distributed Architecture offers the following additional hardware must be introduced for the following advantages: components: • Pass-by CCS softswitch limits: One CCS softswitch can • Front-end computers to load-balance calls on the addi- manage a maximum of 15,000 simultaneous calls. One tional zone SU can manage a maximum of • Media servers to duplicate voice resources (optional) – 10 to 20 calls per second (depending on options) Introducing a new zone with a Distributed Architecture is – 300 to 1,000 simultaneous calls (depending on not necessarily linked to an increase of the telephony sys- options) tem’s capacity. In fact, when considering a mono-CCS softswitch platform managing 60,000 users, the platform • One CCS softswitch can handle a maximum of requires 20 SUs. When migrating to a multi-CCS – 300 calls per second softswitch architecture, the SUs can be shared between the two different zones (10 SUs for each zone). The – 15,000 simultaneous calls OCSC components can remain centralized, since they can manage multiple zones from a single site. – 150,000 users (average usage) The Distributed Architecture shares the system load of OCSC-Distributed Configuration multiple CCS softswitches The OCSC Service Execution and Service Management platforms can be configured in various distributed • Consequently, the platform capacity can be raised. ways to address specific requirements, such as capacity extensions, geographic constraints, and/or disaster recov- • Similarly, it can pass by the OCSC application server ery policies. OCSC SEP can be distributed as application limits, adding more application servers when more servers dedicated to a given application zone (see figure 9 capacity is required at the application layer. on page 10) or as mated pairs handling the same appli- • From a geographic point of view, Distributed Architecture cation zone in load sharing for disaster recovery purposes prevents a single point of failure. In fact, if a location (see figure 10 above). loses IP connectivity, calls can be routed to an alternate When configured as mated pairs, several SEPs can share location. By taking full advantage of the call-routing mod- the same subscriber and application data. Any update ule, multiple backup locations can be defined in order to will be synchronized automatically on the various distrib- provide full telephony service continuity. uted SEPs using the SMP data propagation mechanisms. It is possible to decide to migrate from a single CCS A single OCSC SMP, keeping a centralized provisioning softswitch architecture to a multi-CCS softswitch architec- and management system, can manage distributed OCSC ture. The impact on the architecture is sketched in figure 9 SEPs. A backup SMP can also be provided to address on page 10. disaster recovery requirements for provisioning and management applications. 11
  12. 12. Figure 11 SMC interface with PSTN networks N+1 architecture based on DS10/TS10 OCSC SS7/MTP SS7 network Media GW MGCP SMC H.323 CCS softswitch RTP Legacy switch Other MGWs TRP devices RTP Legacy switch Media GW MGCP Edge domain: SMC (Signaling and SMC supports both E1 and T1 connectivity to SS7 Networks. SMC is also available on Linux with OpenCall Media Gateway Controller) SS7. (Contact your HP representative for details on avail- ability.) SMC: interface with the PSTN networks The interface to the PSTN networks uses the Signaling Distributed implementation and Media Controller. Scalability The distributed processing structure of the HP OpenCall The SMC allows legacy PSTN networks and VoIP networks IN7 ISUP stack allows dimensioning of the SMC, according to be interconnected. to a given requirement, and incrementally increases this SMC consists of: capacity in line with growing network demand. • An SS7 Signaling Control Function that allows connec- High availability tion to legacy PSTN networks based on ISUP (Integrated An N+1 architecture is implemented to ensure the global Services Digital Network User Part) availability of the SMC. This architecture relies on HP IN7, which allows the SMC to be seen as a single point code. • A Media Gateway Control Function (MGCF) that: When a machine fails or is taken down for upgrade or – Controls Media Gateways (the equipment that maintenance, SS7 messages are distributed to the remain- interconnects the voice trunks and the IP-based media) ing machines in order to maintain the global call-handling capacity of the product. The distributed implementation of – Interconnects to IP-based Call Control Networks (e.g., IN7 also allows applications to be insulated from changes H.323 in the current version of the SMC; SIP in the and modifications in the SS7 network. next version) IP standards-based implementation The MGCF maps ISUP messages to H.323 messages (or A major benefit of the distributed implementation is the to SIP messages in the next version of the SMC) and con- standards-based implementation for the Call Control and trols Media Gateways using MCGP (or H.248 in future Media Gateways Control, which allow the deployment of version of the SMC), thus forming the interworking in the the Signaling and Media Controller with virtually any convergent network. Gatekeeper/Proxy server or Media Gateway server in the marketplace. Rely on the HP IN7 ISUP—a proven product The SS7 ISUP connectivity and control are based on the The SMC runs on low-end HP servers (e.g., AlphaServer HP OpenCall IN7 stack implementation, which benefits DS10 or TS10) as illustrated in figure 11 above. from a long and proven experience that: Typically, all calls arriving on an Edge device are sent to • Conforms to the ITU-T, ANSI, and China standards the Class IV domain, except for some specific cases described below. • Is deployed in 180 networks worldwide (wireless and wireline) • Is certified by major telecommunications operators 12
  13. 13. Figure 12 Call failure using “light” Class IV Originating Direct Mode Terminating PSTN CO gateway GK gateway Third-party PSTN network ARQ 123456789 ACF @ TGW Setup 123456789 Setup 123456789 X Release (congestion) Release (congestion) The call is lost! Other PSTN partners may have been able to complete the call. Use of third-party infrastructure softswitches within the “Light” Class IV versus “true” Class IV Edge domain Both “light” and “true” models are fully supported by the The Edge domain can implement its own call-routing or proposed architecture. However, we recommend using load-balancing policies, using for instance, infrastructure the “true” Class IV model. gatekeepers that monitor the state and load of several “Light” Class IV is the simplest way of routing calls in a PSTN gateways. This monitoring is transparent to the VoIP network. It corresponds to the use of direct mode Class IV domain as long as the infrastructure softswitch H.323 gatekeepers supporting the Location Request offers an LRQ-based interface for H.323 or uses SIP. message, or SIP redirect servers. In such a network, any The Edge domain may also be used for direct trunking device willing to make a VoIP call asks where to send the applications that do not require any service, e.g., call set-up message to the gatekeeper or redirect server. leased-line emulation or pure SS7 trunk emulation. In The Class IV service that is offered to the network is this case, some calls may not be relayed through the “light” because it does not provide these useful features: Class IV domain. • A single termination is offered for each call; the Support of media gateways softswitch doesn’t take responsibility for rerouting the The SMC supports Cisco AS53xx media gateway, as well call to alternate destinations if the primary destination as AudioCodes’ Median Gateway. Support of Cisco isn’t responding. In light Class IV networks, the call ter- AS58xx is being validated. Other MGCP gateways can mination rate of the network cannot be better than the be supported after validation. Each validation generally termination rate of the preferred partner on any given requires several weeks to complete. destination. • Alias translation is not possible, requiring a homogeneous Core Class IV domain dial plan inside the network, and smart gateways that Description can convert from the PSTN format to the VoIP intra- The role of the Class IV domain is to route calls between network format and vice versa. application domains, between Edge components, and • CDR generation is gateway-centric, often requiring a between Edge components and application domains. It single vendor network. contains the central routing configuration of the network, including least-cost routing features, and it also implements • Since edge devices have to communicate directly, a the local number portability feature when required. It network with N vendors requires N(N-1)/2 interopera- does not prevent the Edge components from doing their bility tests. own call routing within the Edge domain, if relevant. “True” Class IV Domain mimics the current architecture of The core Class IV domain is composed of one or more PSTN networks. The softswitch combined with the service Call Control Servers, configured as Class IV switches and controller can take full responsibility of terminating all controlled by one or more Service Controllers. The core calls it receives and may try multiple termination devices Class IV domain supports SIP and H.323 call control to terminate a call. As a result, the termination rate of a protocols. network using a true Class IV network is much better than the individual termination rates of each termination device or partner. In order to do this, the softswitch is on the path 13
  14. 14. Figure 13 Rerouted call using “true” class IV Originating CCS OCSC Terminating PSTN CO gateway gateway 1 ... 2 Third-party PSTN network Setup 123456789 Initial DP RR Bcsm Evt/connect Setup 123456789 Setup 123456789 X Release (congestion) Release (congestion) Evt R Bcsm RR Bcsm Evt/connect Setup 123456789 Connect Connect Now the call is properly completed. True class IV resolves network congestion cases, both in the VoIP network and in the PSTN. of all call set-up messages (H.323 routed mode; SIP state- Class V domain ful proxy). Because it is aware of all call-related events, a true Class IV switch can create centralized CDRs that were The Class V domain is responsible for all subscriber- independent of the gateways. True Class IV networks specific features, including: inherently facilitate multivendor deployments; each vendor • Unconditional call forwarding requires only an interop test with the Class IV softswitch. • Time-dependent call forwarding The call flow illustrations in figures 12 and 13 show two examples: The first is a call that fails in the PSTN because • Source-dependent call forwarding of congestion (a very common situation when doing least-cost routing). The congestion is reported using a • Redirect on busy or no-answer calls Q850 error code. A light Class IV network cannot recover • CLIP/CLIR (Calling Line Identification Presentation/Call- from this situation, while a true Class IV network can, as ing Line Identification Restriction) noted in figure 13. • Call blocking Interfaces with other domains Calls received from the Edge or Application domains • Legal interception The Class IV domain receives calls from the Edge domain In order to improve scalability, the Class V domain does on IP address IPcore, optionally using an H.323 LRQ mes- not maintain CPE (Customer Provided Equipment) registra- sage in which case, the IP address used to forward the tions directly, but communicates using LRQs with one or Q931 signaling is specified in the LCF. For SIP, a regular several Access domains that maintain this information. INVITE message is used, indicating a user or service is being invited to participate in a SIP-based call session. This distributed design allows operators to resolve issues associated with centralized designs when the network Calls sent to the Edge or Application domains starts. It also facilitates the use of multiple CPE vendors, Depending on the Edge domain device, the Class IV domain by allowing the deployment of CPE-specific access servers can either send an LRQ message or send a direct Setup as required. (See the “Access domain” section below for message to the proper IP address. If an LRQ is used, the IP details.) address used to forward the Q931 signaling is expected in the LCF. For SIP, a regular INVITE message is used. 14
  15. 15. Access domain IP Media Server The Access domain is composed of direct mode gate- The HP Media Server solution set offers a robust and scal- keepers for H.323 (or Registrars for SIP), usually from the able platform for the development of value-added services same vendor as the CPE vendor to ensure interoperability applications, supporting thousands of simultaneous calls of security mechanisms. in a wide variety of telecom configurations. Media Server, in its three major configurations for Service providers The role of access gatekeepers is to: (Intelligent Peripheral, IVR, and Service Node), is a tool • Maintain registrations of CPE, as well as keep-alive for the implementation of multiple customer applications, registrations such as network announcements, unified messaging access, voice portals, and IP voice mail. For a complete list of “supported” (tested) The Media Server comes with the following applications: endpoints, contact your HP representative. • Network announcements—allows call mapping of cer- tain numbers to prerecorded announcements. • Simple voice mail—allows recorded voice messages— when the end-user CPL call management rules instruct the voice platform (softswitch + OpenCall)—to forward to e-mail. The e-mail addresses of end users are stored in their profiles in the LDAP directory, and the Media • Respond to the ARQs of devices and point to the Class Server sends an SMTP mail with the voice message as V CCS for all authorized calls an attachment to the address of the user. The voice mail then appears as a regular voice mail message in the • Block call attempts from CPEs to destination numbers not user mailbox. authorized by the local dial plan (for instance, a ported prefix) • Advanced voice mail (optional)—is included if the mail server also supports IMAP 4 mail retrieval, and it allows In addition, the Access domain includes all necessary users to consult and manage voice mail by phone. The servers to allow CPE to download their firmware and application needs to be configured with the user configuration, including the registration alias, security mailbox password in the user LDAP profile (for security parameters, and software keys that limit features of the CPE reasons). Note: HP does not provide the SMTP mail (e.g., multiple call handling or three-way conferencing). server as part of the basic offering, and the provisioning If a CPE authentication scheme is required, the Access tool only configures the LDAP user profile. User mailbox domain will also require authentification servers, such as creation and management are done using the tools pro- RADIUS servers. vided by the mail server vendor. Using a separate Access domain facilitates dimensioning • Other applications can be developed on top of the the network. While the Class V and Class IV domains VXML environment. scale according to the number of simultaneous calls in the network, the Access domain scales proportionally to the number of CPE lines. The relative sizes of the two domains may vary widely according to average line usage. A very low line usage (typical of software endpoints) will require a generous sizing of the Access domain, but relatively less capacity in the Class V domain. A higher line usage (e.g., hardware CPE or high-usage lines, such as call cen- ter agents) requires the exact opposite dimensioning. Redundancy in the access zone with such gatekeepers is achieved using the “alternate gatekeeper” feature or clustering pairs of Access gatekeepers. Current Access gatekeeper is supported by the Cisco IOS gatekeeper. Other H323 gatekeepers could be supported after validation. For endpoints using the MGCP protocol, Access domain management is performed by the SAU. This unit manages MGCP endpoint registrations, as well as multiline features, which are not handled by MGCP devices because of the protocol’s design. 15
  16. 16. Endpoints Conclusion The HP solution supports multiple endpoints: H323, SIP, MGCP and either soft phones, IP hard phones, or analog The HP VoIP solution offers a unique and optimized phones. The solution can also support H323 “video” combination of open/scalable architecture and a set phones. For a complete list of “supported” (tested) of features enabling service providers to: endpoints, contact your HP representative. Other • Deploy rapidly an off-the-shelf, ready-to-operate-and-bill endpoints can be supported after validation. service • Integrate a solution with current legacy technology, thanks to a complete set of traditional TDM or IP capabilities HP focuses more than 25 years of • Enhance applications and their functionality by telecommunications expertise into a powerful customizing them to adapt to specific requirements integrated team, the Network Service • Develop an architecture and a set of products that guar- antee medium- to long-term evolution—in the pure IP Provider Business Unit (NSPBU). space, as well as in the converged 3G and multimedia IP communication space Communications solutions are highly complex, and serv- Management: FACPS (fault, accounting, configuration, ice providers must deliver even more innovative services to performance, security) the market while keeping customers loyal and insulated • Fault management—the CCS and OpenCall platforms from the complexities behind the services. In order to provide SNMP traps that can be integrated in HP achieve this, service providers need strategic partners that OpenView. can do more. HP offers a range of targeted, seamless solutions that are integrated with partners and delivered • Accounting—HP OpenCall generates CDRs (call data quickly and efficiently. HP systems and solutions are open records) that can be collected by billing platforms. and flexible, empowering customers to customize or • Configuration-service configuration—HP OpenCall pro- create value-added services. Our service capabilities vides the Service Management Platform, which provides provide the expertise to develop, integrate, test, install, all configuration data for the VoIP value-added services. and support the most complex service launches. This A Web-based application is provided using these data one-stop shopping approach lets service providers focus and enabling the operator, as well as end users, to on their customers—not their suppliers. configure their profiles. HP focuses more than 25 years of telecommunications • Network configuration—network configuration is being expertise into a powerful integrated team, the Network taken care by the network infrastructure solution, gener- Service Provider Business Unit (NSPBU). The NSPBU, ally using an HP OpenView system-based solution. along with 500 valued solutions partners, assists the world’s top 200 service and equipment providers and • Performance—the HP platform provides MIB information, meets the voice and data needs of hundreds of millions of configurable to generate performance data. HP platform wireline and wireless subscribers. can also provide online statistics on calls. With solutions, technologies, and services—including HP • Security—the HP platform is a fully multitenant carrier- OpenCall and HP OpenView telecommunications capa- grade platform where each customer’s data is totally bilities arrayed across network infrastructure, network secure and not accessible by other customers. In terms services, operations and business support, mobile and of user authentication, a login hierarchy is available rich media solutions, and end-user access—the HP with different profile configurations, from administrator NSPBU is a major player that is leading the network and and basic operator to different categories of end users. service provider industry. Internet security related to address plan—public, private addressing—is also being taken care of with adjacent components (optional) that enable proxy functionality. 16
  17. 17. Figure A-1 CCS logical diagram Q.1224 with IN Services Provisioning Supervision Accounting/billing VoIP-specific aspects (Internet addressing, Detection Call routing SPE SNMP ASM registration, …) points engine IN state machine Routed gk Proxy Server Registrar CCS H.323 SIP Appendix A: Interfacing VoIP IN call model supported by the CCS As already mentioned in an earlier section of this infrastructure with existing IN services document, the CCS product is a VoIP Softswitch providing advanced call control architecture and implementing an Introduction IN call model (Q.1224) with additional detection points The objective of this appendix is to describe how IN that take into account specific aspects of the VoIP frame- services already deployed in the PSTN network can work (e.g., registration, a mobility function). be accessed from subscribers connected to a service provider’s Voice over IP (VoIP) network. These VoIP-specific additions are further referred to in this appendix as INAP CCS extensions, and they are marked The proposed approach consists of delivering a trial solu- with an asterisk (*) in some of the diagrams and call tion to the service provider to validate the target solution flows on the following pages. and further identify any specific requirements in this area. A Detection Point (DP) is associated with each Q1224 In the sections below, it is assumed that the target VoIP state. A default action that will be the “next step by network is based on HP’s standard VoIP solutions. In default” can be defined for each DP. particular, the CCS Softswitch offers the VoIP network core-switching function. Options exist for filters to be positioned on every DP: If a filter is positioned on a DP, the action is passed on to the The proposed interface between existing IN services and Service Control Point; if there is no filter associated to a the VoIP network will be implemented by an Intelligent DP, the process is continued on the CCS softswitch. Network Application Part (INAP) gateway supporting a standard INAP over SS7 interface toward the PSTN Filters are either static or dynamic, are defined at the sys- network and an extended INAP over IP interface toward tem initialization, and can be modified “on the fly.” the VoIP network core-switching function. There are two types of Detection Points for which actions • The PSTN network interface (i.e., INAP/SS7) of the have to be triggered on the SCP. gateway is based on proven HP OpenCall SS7 and IN software currently deployed in almost all operator 1. “For information”—the DP and its associated parame- networks worldwide. ters are sent to the SCP, but CCS doesn’t wait for any feedback from the SCP. Next state is the default one. • The VoIP network interface is based on the state-of- the-art extended INAP interface delivered by the CCS 2. “Blocking”—The DP and its associated parameters are Softswitch, which is also deployed in large VoIP sent to the SCP, and CCS waits for a return from the SCP networks worldwide. or for a Timeout that puts the process in the next state. The sections below describe the core switching functions Returns from the SCP are of the CCS softswitch support-standard INAP call model, • DP parameters that will be changed and the next state the proposed gateway architecture, and the IN call flows is the default one. supported for the trial. • The next step is not the default one, but the Service Logic, which has been activated, defines it. 17
  18. 18. Figure A-2 CCS O-BCSM and T-BCSM Originating—basic call state machine Terminating—basic call state machine O null O exception O abandon T null T exception Origination_attempt T abandon Authorize origination attempt Termination_attempt Origination_denied Authorize termination attempt Origination_attempt_authorized Termination_denied Collect information Termination_attempt_authorized Collect_timeout Select facility Collected_information Analyze information Facility_selected_and_available Invalid_information Present call Collected_information Presentation_failure Select route T_no_answer Call_accepted Route_select_failure T alerting Authorize call set-up Call_rejected Author_route_failure T_mid_call T_answer Send Call O_called_party_busy T active T_active_failure O_term_seized T_mid_call T_suspend O alerting O_no_answer T suspended O_mid_call T_suspend_failure O_call_rejected O_answer T_disconnect O active O_active_failure O_mid_call O_suspend O suspended O_disconnect O_suspend_failure Figure A-3 INAP gateway overview SCP INAP gateway OCSC/CCS IN services call model Call model Q.1224+ ITU-T INAP INAP* ITU-T INAP INAP* ITU-T TCAP TCAP* TCAP* ITU-T TCAP ITU-T SS7 UDP* SCCP/MTP UDP* ITU-T SS7 layers SCCP/MTP layers IP IP * Protocol variant or including VoIP extensions 18
  19. 19. Figure A-4 Figure A-5 Scenario 1—basic call Scenario 2—call aborted (time out) SCP IN AP GW CCS SCP IN AP GW CCS (*) InitialDP (*) InitialDP TC_begin TC_begin • Initial IDP • Initial IDP TC_end TC_continue 1. Furnish charging (*) Connect 1. Furnish charging info info 2. Send charging 2. Send charging info info 3. Connect 3. Request report (*) Abort BCSM event (**) Intermediate CDR generation by IN AP GW 4. Connect INAP-CS1 Component (transported in TCAP/SS7 message) TC_abort (*) Extended INAP component (transported over IP) (**) Optional specific charging capabilities (to be discussed and (**) Intermediate CDR generation by IN AP GW agreed prior to delivery) Figure A-6 Figure A-7 Scenario 3—called party busy or no answer Scenario 4—call answered or abandoned Note: This scenario could continue recursively or end as per scenarios 2 and 4. SCP IN AP GW CCS SCP IN AP GW CCS (*) InitialDP (*) InitialDP TC_begin TC_begin • Initial IDP • Initial IDP TC_continue TC_continue 1. Furnish charging 1. Furnish charging info info 2. Send charging 2. Send charging info info 3. Request report (*) Connect 3. Request report (*) Connect BCSM event BCSM event 4. Connect 4. Connect (*) Event report BCSM (*) Event report BCSM • O_no_answer or • O_answer or TC_continue TC_end (pre-arranged) • O_busy • O_abandon Event report BCSM Event report BCSM • O_no_answer or • O_answer or • O_busy • O_abandon (*) Intermediate CDR generation by IN AP GW (*) Intermediate CDR generation by IN AP GW The CCS undertakes Gatekeeper/Registrar operations. CCS is also capable of modifying the IP telephony signal- (For instance, in H.323, RAS and call routing are based ing “on the fly,” making the implementation of a number on H.225 and H.245.) Therefore, the pure IN Detection of services possible. CCS capabilities are critical in the Points (DP-alerting, DP-connect) are enriched by sense that they implement call-switching functions, as well H.323/SIP–derived Detection Points (DP-register, as sorting and sequencing the call progression phases. DP–admission-pending). CCS Detection Points make it possible to trigger specific processing during the different steps of a call (e.g., con- necting, busy, no answer, and so on) or upon reception of H.323/SIP–specific events. 19

×