Trillium-TCAP. White Paper. Overview CONTENTS

Transcription

1 White Paper Trillium-TCAP Overview Fixed and mobile telecommunications as well as the global Internet are two world changing technologies that have revolutionized how people and business communicate. Both the telecommunications revolution and internet technology started due to military requirements, but over the past 20 years both the internet and telecom grew by leaps and bounds in the public sector. During last five years, as people have leverage telecommunications and the internet for business purposes there have been major innovations in e-commerce that have levied new requirements on the traditional TCP/IP network paradigm. As a result, the internet has grown much beyond basic data transport services to include advanced application development frameworks including JAVA, xml, dotnet, c#, frameworks, templates, and so on. CONTENTS Intelligent Networks and TCAP pg.2 Internet and SIP pg. 3 Convergence of IP and IN pg. 4 Web Services and SOAP pg. 4 TCAP Web Server using gsoap pg. 5 Solution Example: TCAP Web Server pg. 6 Services Examples pg. 7 References pg. 8

2 2 The Web Server Application is one of the popular frameworks leveraged by developers to deliver new services over the Internet. Original Equipment manufacturers leverage this capability to provide readily deployable application servers. These servers allow dynamic web page generation and implement services like clustering, fail-over and load-balancing, so developers can be focused just on implementing the business logic of the target application. Usually based on JAVA these web servers are popularly known as J2EE servers e.g. Apache Geronimo, JBoss, Weblogic, Websphere etc. Exploiting 4th generation programming languages via easy to use web servers has rapidly grown in popularity and the percentage of complex but user friendly websites using J2EE is enormous. While the internet expanded and continues to do so with a sharp focus on improving the end user experience it was not until recently that telecommunications networks have attempted to move beyond its own traditionally closed intricacies. Traditionally the foundation of telecom networks have been C based software stacks and lightweight but C based end user Application Programming Interfaces (API). Only in recent years has the telecommunications sector has adapted to use more web based interfaces along with custom applications. This however has primarily been limited to Network Management Systems (NMS) and Element Management Systems as well as the Operational Support Systems (OSS) and Business Support Systems (BSS) side of the telecommunications network Despite the potential of many web related e-applications being deployed on top of existing standard telecommunications APIs the deployment of web server or JAVA based applications has been limited. The challenge is that there are limited tools that make available the underlying services of the telecommunications network to application developers in an easy to use and familiar web server environment. The solution is to add a web services API interface on top of its integrated standards based signaling and data plane telecommunications protocol stacks which offers the application developer access to these protocols for communication purposes via a straight forward and familiar web server interface. Some examples of solutions such as this include a Radisys offering which includes a WSDL interface ported on top of deployment proven Trillium protocol stacks. With solutions such as this application developers can now write complex applications in the programming language and/or platform of their choice using the web services request and response without delving into the details of the specific protocols or getting restricted by inflexibility of C/C++ APIs. Intelligent Networks and TCAP The Intelligent Network standards provide a framework for service-oriented architecture based networks, which separate the service control functionality from the switching functionality. The aim is to provide seamless service to all subscribers regardless of underlying switching network which include ISDN, PSTN, PLMN, and so on. Before IN was developed, new services had been implemented in the switching system itself. This is a tedious task as debugging the switch takes considerable time and is an inflexible method as often new services required costly changes to the foundational switching network. This approach leads to slow deployment of new features or services and stalled innovation. The main advantage of Intelligent Network is that the new services are introduced without any changes in the networking infrastructure. This means new services are deployed faster and less expensively. In addition to the Intelligent Network construct another important aspect of rapid service deployment is the requirement for a generic service architecture that works over different switching networks. Additionally, the service deployment framework should be designed so that new features or services can be added easily with the reuse of existing service or feature components. Hence the concept to develop generic and reusable service components such as authentication, number translation, charging etc. which could be used across various applications. Premium Rate and Card Calling are some of the several examples of IN Services using reusable service components. In summary, IN aims to support both service and network independence while providing many innovative services.

3 3 The IN relies on the Signaling System 7 (SS7) network, which forms its backbone. SS7 provides the basic infrastructure needed for the IN. There are multiple network elements in the IN including: Service Switching Point (SSP) the SSP provides local access services as well as an ISDN interface to the Service Transfer Point (STP) Service Transfer Point (STP) the STP provides packet switching of message-based signaling protocols in IN to the Service Control Point (SCP). Service Control Point (SCP) the SCP provides access to the IN subscriber database and is connected to a Service Management System (SMS). Service Management System (SMS) the SMS provides a graphical user interface to the subscriber database which supports update and overall management of the database. Intelligent Peripheral (IP) the IP provides resource management of devices such as voice response units, voice announcers, and DTMF sensors for caller-activated services. The IP is accessed by the SCP when service demands interaction. Figure 1 illustrates the IN architecture. Within the IN protocol framework Transaction Capabilities Application Part (TCAP) is an application layer protocol which provides generic services for the information transfer between applications in the SS7 network. It uses standards defined set of data elements to support the information transfer. TCAP is based on the concept of components. Components are a means of invoking an operation on remote node. A TCAP message can contain several components. In TCAP, transactions are a set of related messages that are exchanged between nodes. The services of TCAP are provided according to two sub-layers. These are the component sub-layer and the transaction sub-layer. When a call is placed in the IN, a request for call handling instructions is sent to the SCP using the TCAP protocol. The database provides the instructions for handling the call based on the customized service instructions programmed by the subscriber, and sends them to end office switch. Figure 1: IN Architecture The call setup and teardown is handled using the conventional SS7 protocol. Many services and features offered by the network are based on the database linked to SS7 network through the SCPs Local end offices and other networks can access the database by sending database query messages through the SS7 network to the SCP. These databases are used for intelligent call routing, Local Number Portability, Prepaid services, VPN and other intelligent network services. These services can be accessed through the TCAP messages exchanged between SS7 network elements. Internet and SIP As early as five years ago and even for many people today there is a hard reliance on expensive circuit switched mobile and PSTN networks to carry voice calls over short as well as long distances. However, the advent of Voice Over IP (VoIP) has delivered a cost effective solution that leverages the widely deployed Internet for delivering voice services. Instead of sending signals via a Circuit Switched network, VoIP application generally uses the Session Initiation Protocol built on top of the TCP/IP framework of the internet to create setup voice and video calls or sessions over IP networks. SIP is now the de-facto foundational protocol in many VoIP solutions. It is a signaling protocol used for establishing sessions in an IP network. SIP not only provides the ability to establish real-time calls and conferences but also enables a number of innovative

4 4 services, such as voice-enriched e-commerce, web page click-to-dial, Instant Messaging with buddy lists, and IP Centrex services. SIP is a request-response protocol that closely resembles two other Internet protocols, HTTP and SMTP (the protocols that power the World Wide Web and ); consequently, SIP sits comfortably alongside Internet applications. Using SIP, telephony becomes another web application and integrates easily into other Internet services. SIP is a simple toolkit that service providers can use to build converged voice and multimedia services. In order to provide telephony services there is a need for a number of different standards and protocols to come together specifically to ensure transport (RTP), to authenticate users (RADIUS, DIAMETER), to provide directories (LDAP), to be able to guarantee voice quality (RSVP, YESSIR) and to inter-work with today s telephone network. Prevalent with Web Application Development, JSR has standardized SIP Servlet APIs. SIP Servlets, run in a SIP container, and are similar to HTTP Servlets, but also support the SIP protocol. Together, SIP and SIP Servlets, are behind many popular applications that provide VoIP services. Convergence of IP and IN Advanced services can be provided on the top of VOIP networks with the usage of IN Services such as Unified Messaging that can be delivered to as to the called party. Also provisioning of services where query specific to PSTN Network becomes a requirement picture. Additionally, operators who are today providing a series of calling services to their subscriber base on the legacy IN infrastructure want to continue to provide these same services as they transition subscribers to a more cost effective all IP based network that uses VoIP frameworks. For using such integrated service, a mechanism is required by which a network element that has the ability to utilize SIP signaling can make use of PSTN features via SS7 TCAP signaling. For using any of the services of PSTN networks, SIP signaling information must traverse the IP network to a Signaling Gateway to get access to the SS7 network. Figure 2: Signaling in SIP/TCAP Gateway There are two parts to this problem. First, the SIP endpoint needs to format a binary TCAP message or it use an intermediate representation that is then converted to a binary TCAP message by the Signaling Gateway. Second, the SIP element needs to use SIP itself for the transport or possibly some other transport mechanism to deliver the TCAP message to the Signaling Gateway. The solution in this paper recommends the use of gsoap messages to transport and receive an intermediate representation of a TCAP message from the SIP endpoint to the Signaling Gateway. Figure 2 illustrates the flow of signaling in the SIP/TCAP based signaling gateway. Many intelligent services can be built leveraging this integration gateway. For example, Local Number Portability (LNP) is one of the services that can be achieved through this gateway. URI is a string of characters for identifying a resource on Internet. In SIP, URI is an addressing scheme for identifying caller or callee. E.164 is an international numbering plan for public telephone systems in which each assigned number contains a country code (CC), a national destination code (NDC), and a subscriber number (SN). When the SIP Server receives an INVITE request, it extracts the useful info (E.164 number) from the request URI. It builds the TCAP request in the form of SOAP client and sends it to the TCAP web server using gsoap. Similarly, if a SUP server receives the 800 Number request in the request URI, it builds an equivalent query using SOAP client and send it to TCAP server using gsoap. Web Services and SOAP A web service is a network accessible interface to application functionality that is built using standard Internet software languages. Web services provide an abstraction layer between the client and application. Most web services today, like booking a ticket or banking, are provided through HTML websites.

5 5 Application services are provided through the use of HTTP protocols and HTML data formats. Both the client and server application understands these standards and interact with the web services for different services such as ordering a plane ticket or buying a book. Because of these standards, it does not matter whether the Application is written in C++ or JAVA. Precisely, web services are capable of sending and receiving messages using HTTP internet protocol and some defined message format understood by the client and/or server. The most common example of web services is to call procedures running on the application server. For the application data to be communicated between client and application, it needs to be in a common format. HTML is a kind of packaging format, but it is not very suitable to convey the meaning of specific data elements. XML is the most common packaging format because it represents the meaning of data more closely through the use of metadata tags. Additionally, XML parsers are easily available via the open source community. SOAP is very common and popular packaging format built on top of XML. SOAP can also be thought as a sort of Remote Procedure Call (RPC) that uses XML. SOAP is an XML-based protocol from the W3C for exchanging data over HTTP. It provides a simple, standards-based method for sending XML messages between applications. Web services use SOAP to send messages between a service and its client(s). Because HTTP is supported by all Web servers and browsers, SOAP applications exploit a wire-protocol (typically HTTP) to communicate with Web Services to retrieve dynamic content. For example, SOAP can be use to deliver real-time stock quote information of a stock portfolio that can be graphed on the display of a cell phone or can be analyzed within a spreadsheet program running on a desktop computer. SOAP neither enforces client service architecture nor supports P2P architecture. Web Service Definition Language (WSDL) is a XML based format for describing Web Services. It described the subroutine and its argument through which a service is to be accessed. WSDL is an XML-based format for describing Web Services. Clients wishing to access a Web Service can read and interpret its WSDL file to learn about the location of the service and its available operations. In this way, the WSDL definition acts as the initial Web service interface, providing clients with all the information they need to interact with the service in a standards-based way. Through the WSDL, a Web Services client learns where a service can be accessed, what operations the service performs, the communication protocols the service supports, and the correct format for sending messages to the service. SOAP messages are in XML documents format. Data is sent between the client(s) and the Web service using request and response SOAP messages, the format for which is specified in the WSDL definition. Because the client and server adhere to the WSDL contract when creating SOAP messages, the messages are guaranteed to be compatible. A large no of SOAP Toolkits are available for different programming languages. In short, SOAP is a protocol that uses WSDL to deliver Web Services in a standard and extensible fashion. TCAP Web Server Using gsoap gsoap is an open source SOAP Toolkit for C and C++. The gsoap tools provide an automated SOAP and XML data binding for C and C++ based on compiler technologies. The tools simplify the development of SOAP/XML Web Services and XML applications in C and C++ using automatic code generation and advanced mapping methods. gsoap provides a transparent SOAP API through the use of compiler technology that hides irrelevant SOAP-specific details from the user. The compiler automatically maps native and user defined C and C++ data types to semantically equivalent SOAP data types. As a result, full SOAP interoperability is achieved with a simple API relieving the user from the burden of SOAP details and enabling her to concentrate on the application-essential logic. The gsoap stub and skeleton compiler provides a unique SOAP-to-C++ language binding for the development of SOAP-enabled applications such as clients, services, and peers.

6 6 An example of the WSDL code is as follows: <element name="tcapdialogrequest"> <complextype> <sequence> <element name="version" type="xsd:string" default="beta"/> <element name="retransmitted" type="xsd:boolean" minoccurs="0" maxoccurs="1" default="false"/> <element name="dialogreqevent" type="impl:dialogreqevent" minoccurs="1" maxoccurs="1"/> <element name="componentreqevent" type="impl:componentreqevent" minoccurs="0" maxoccurs="10" /> </sequence> </complextype> </element> TCAP services can be provided as a web service to any third party who is hosting a VOIP Application such as a SIP proxy Server for a 800 Number translation service. VoIP applications can have a TCAP client code embedded in their application and by leveraging SOAP/WSDL can request a TCAP Begin or Continue message.. Essentially, the embedded client can make TCAP requests of the IN using SOAP without detailed knowledge or interaction with the underlying SS7 transport. This means VoIP applications can leverage existing TCAP based IN applications and services in delivery of their services ensuring application re-use and service continuity. After designing the WSDL the client and server side code can be generated using the gsoap provided tools. Whenever a VOIP application wants to make a request it will use the generated client code (i.e. a function call) to make any telephone related query in the IN. The most important advantage of this architecture is that even if the client is using a JAVA based application the Web Server it can use C based implementation over a common WSDL/SOAP infrastructure. This is a very similar approach as used in the CORBA framework and WSDL may be compared with IDL in JAVA. Solution Example: TCAP Web Server This section provides an example solution that leverages proven Trillium TCAP and standard WSDL/ SOAP to deliver a TCAP gateway application. This gateway allows any VoIP entities to access the TCAP based IN services hosted in a traditional SS7 network. It may be deployed as a nationwide hosted database or an SCP in a specific carrier s network. Service requests originate from a SIP proxy server, or any VoIP entities, and the TCAP gateway is gsoap based. The interface files are provided in the form of WSDL (XML Files) that provide the details of the TCAP services. Using these files client code is generated to be embedded in the VoIP/SIP based application. The following diagram illustrates this solution approach. The WSDL defines the interface to the TCAP stack and is derived from the standard Java programming API for TCAP, JSR11. There are two separate WSDLs defined for communicating with the TCAP interface for simplicity and brevity: 1. send.wsdl this is used to send a TCAP Web Service from SIP Servlet to the TCAP interface. 2. process.wsdl this is used by the TCAP interface to send web service from the SS7/SIGTRAN to the Servlet.

7 7 The WSDL allows the application to specify all parameters associated with the SCCP N-UNITDATA request primitive, including all variations of the routing parameters (Destination PC + SSN, Global title, Routing Indication, etc ) when sending a message. Figure 3: Signaling in SIP/TCAP Gateway Following represents a typical scenario flow. TCAP Web Server is used as the Gateway solution to the VOIP entity as shown in the call flow below for any services hosted by the SS7 networks SCPs. The UE receives an INVITE which is translated into the TCAP Web query using the gsoap client code. The TCAP web server application passes this query to the STP/ SCP after receiving on the gsoap server interface. The TCAP Gateway Stack architecture is shown in the figure below. It contains the TCAP protocol stack which consists of multiple protocol layers including TCAP, SCCP, M3UA and SCTP protocols. The TCAP solution also provides a Stack Manager for the protocol stacks which provides initialization, configuration and general Operations, Administration and Maintenance (OA&M) functionality. The solution also provides high-availability through a activestandby configuration. The proven Trillium Fault Tolerance High Availability (FT/HA) is used here, but for simplicity is not illustrated in the diagram. Figure 4: Message Flow in SIP/TCAP Web Server Services Examples This section outlines a few services that can be enabled using a WSDL/SOAP based TCAP Gateway. Originating Call Screening (OCS) OCS is a service whereby the Proxy Server ensures that the caller is authorized to initiate a call to the dialed number otherwise known as the callee. When the SIP proxy server receives an INVITE request, it extracts the Request-URI (an E.164 number) of the party being invited and sends it, along with other information, to the TCAP Web Service client. The TCAP Web Server Application proceeds through Web Service Interface, triggers a TCAP (or INAP) request to the Figure 5: Trillium TCAP Gateway Architecture SCP. The SCP analyzes this request and instructs the SIP proxy server on what to do next with the call. The SCP has access to a user profile database which contains, among other fields, a field which restricts the caller from making certain calls (for example, 900 number calls, which in the US are billed at higher-than-normal rates).

8 8 Example 1: Caller wants to initiate a call to a 900 number: Caller->Sip Server: INVITE sip: @ccpu.com;user=phone Sip Server ->Caller: SIP/ Forbidden Local Number Portability (LNP) Number portability can be classified into three types: Service Portability, Service Provider Portability, and Location Portability. Service Provider portability is defined as the ability of an end user to retain the same E.164 international public telecommunication number when changing from one service provider to another. Example 2: Caller calls a number, which has been ported: Caller->Sip server: INVITE sip: @ccpu.com;user=phone When the SIP proxy server receives an INVITE request, it extracts the Request-URI (an E.164 number) of the party being invited and sends it, along with other information, to the TCAP Web Server Client. The TCAP Web Server Application triggers a LNP TCAP (or INAP) request to the SCP. The SCP analyzes this request, and after consulting a LNP database returns the new routing number to the SIP proxy server. The SIP proxy server forwards the request to the next hop SIP server, after modifying the Request-URI to include the new routing number: Sip Server->Next Sip Server: INVITE sip: @ccpu.com;user=phone The determination of the next hop SIP server can be done various means. In our case, the next hop SIP server happened to be a properly registered User Agent Server belonging to the callee, so the INVITE was simply proxied to it. References 1 gsoap User Guide 2 Radisys Trillium+plus TCAP Solution 3 draft-miller-sip-tcap-00.txt 4 SIP RFC draft-gurbani-iptel-sip-in-imp-01 Corporate Headquarters 5435 NE Dawson Creek Drive Hillsboro, OR USA Fax Toll-Free: info@radisys.com 2011 Radisys Corporation. Radisys, Trillium, Continuous Computing and Convedia are registered trademarks of Radisys Corporation. *All other trademarks are the properties of their respective owners. September 2011