Requirements of a Telecommunications SOA

Unarguably, the intelligence in the telecommunications networks continues to move out to the edges. Early analog phone systems were completely centralized. Call processing and service execution were often intertwined and occurred on centralized platforms owned by the telephone company, and also often used networks owned by the same telephone company. Digital switching systems coincided with the separation of call signaling from service execution (the IN concept). The intelligence was more distributed here and, in fact, it was not strictly necessary that the service execution platform be owned by the same provider that owned the switch (although this was, by far, the most common deployment scenario).

The advent of the mobile cellular network furthered the move of intelligence to the edges. The first-generation (1G) cellular network was an analog circuit-switched system. Mobile handsets were bulky, voice quality was poor, and security was nonexistent. 2G networks improved on the disadvantages and provided additional data services, like Short Message Service (SMS). 2.5G is an intermediate step toward 3G, utilizing Internet protocols and packet switching in portions of the cellular network. 4G networks are a step beyond 3G, providing data transmission speed equivalent to a local area network and more personalized services for its subscribers. As can be observed, in successive generations starting from 2.5G, the Internet Protocol plays an increasingly bigger role, and the mantra of the Internet Protocol is that intelligence resides at the edges [KEM04]. Thus, if the underlying telecommunication technology is moving toward the Internet Protocol, there appears to be some promise in the argument that the telecommunications service architecture will also evolve toward a computing-based one. Initial stages of this progression are characterized by the crossover services model, whereby both networks are cooperating to execute the services [GUR04a, GUR05a]. The final stages will witness the wholesale move of telecommunication services to the Internet, thus establishing a telecommunications SOA.

The as yet unanswered question is: What shape will this new architecture take? Let us first examine the similarities and differences between the service models of the two networks, and then attempt to tease the requirements of a telecommunications SOA.

The biggest similarity between the service models is that they both use message passing as an underlying mechanism for service execution. In the telecommunications network, an SSP sends a well-formatted message — a request — to the SCP, which in turn sends a well-formatted response back. This interaction matches the Web services description of exchanging structured information in a distributed environment. Thus, at a very high level, both networks contain primitives to name resources and route messages between the resources.

Closely related to message passing is the desire to use standardized protocols to transport these messages. Within their respective domains, both Web services and telecommunications services use standardized protocols for message passing. Web services use XML, SOAP, UDDI, and WSDL, whereas telecommunication services use protocols such as SS7 [RUS02] and Intelligent Network Application Part (INAP) [FAY96].

A second similarity lies in the manner services are defined within the computing discipline. In computing, a service can be described as an autonomous, platform-independent computational element. This is also true of telecommunication services. The autonomous, platform-independent computing element in telecommunications services is called a SIB (introduced in Section 2.2). Application programmers in telecommunications typically use a palette of well-known SIBs; creating a service is as simple as dragging a SIB and connecting it to other SIBs through edges that represent the actions and events (of course, the service has to be compiled and tested before being widely deployed). A SIB, much like a computing service interface, absolves the programmer from knowing the internal protocol details [WIL97].

A third similarity is the need for orchestration. An example will illustrate: Consider a stock price Web service that returns the stock price of a certain company. In and of itself, it is a useful service, but when it is coupled with another service — call this the stock-purchasing service — that purchases the stock when it falls to a certain price range, the utility of the stock price service is increased. The need for orchestration arises because some intelligence is required to trigger the stock-purchasing service when the price falls below a certain watermark. The business community, lead by IBM, Microsoft, and others, is coalescing around an orchestration language called Business Process Execution Language (BPEL). Other domain-specific orchestration languages and coordination strategies will undoubtedly emerge as the Web Services Architecture matures.

In telecommunication services, orchestration is already present in the form of a call controller. A call controller can be thought of as a service that is instantiated when a caller initiates a call, or it can be instantiated based on other service logic (i.e., at 3:00 p.m., start a conference call between the following people...). The call controller is the intelligent centralized entity that controls all aspects of the call: it knows the number of parties in a call, the duration of the call, billing information of the call, and so on. As an advanced example of coordination in telecommunication services, imagine that there are two discrete services: a presence service that determines where a subscriber is present (home, in transit, work) and an instant message service that can communicate with the subscriber. The call controller can use the presence service to locate the called party, and it could use the instant message service to first send an IM to the called party and explicitly ask its disposition before allowing the called party's phone to ring.

Having examined the similarities, we now enunciate the differences. The first and most apparent difference between the two service architectures lies in the realm of discovery, selection, and binding of services. The Web Service Architecture includes WSDL and UDDI to aid in this effort; an equivalent mechanism in telecommunications services is missing. One possible reason for this is that in the telecommunication domain, the service vendor and the service provider typically have preexisting business relationships, thus alleviating the need for service discovery and binding. This is not the case for Web services. A Web service written by an arbitrary service vendor should, at least in spirit, work across the platforms of multiple service providers. This process automatically results in the best-of-breed services percolating to the top of the list. There is no equivalent for discovery, selection, and binding in the telecommunications network. Preexisting business relationships between the service provider and the network vendor have alleviated the need for this (traditionally, the service providers have been the equipment vendors, who create and sell services directly to the network providers, who in turn bill their subscribers for these services). It thus follows that some manner of a discovery, selection, and binding mechanism based on open and standardized protocols should be a requirement of a telecommunications SOA.

A second difference lies in the real-time nature of telecommunication services versus Web services. The latter are mostly data driven, i.e., move information from point A to point B. These services can withstand delay and are generally more forgiving in the face of a best-effort network like the Internet. Web services are also characterized by a single protocol for communications (SOAP) and data representation (XML). Telecommunication services, on the other hand, are both data driven and media driven (e.g., voice, video, gaming, and presence). They do not suffer delay in a graceful manner. This is true at both the media layer (delay in terms of lost packets introduces jitter and an inferior audio/visual experience) and the services layer (delay in accessing a database may prohibit the productive execution of a service). They also tend to be driven by a multiplicity of protocols: Session Initiation Protocol (SIP), SDP, Real-Time Transport Protocol (RTP), and Real Time Control Protocol (RTCP), to name a few. Thus, a second requirement of the telecommunications SOA would be support for real-time delivery of information across a multiplicity of protocols.

Another difference is in the security infrastructure of the networks. In the telecommunications network, security is addressed at two different layers. At the physical layer, the telephone lines and equipment (switches, base stations) and related databases are located in secure facilities. It is hard, although not impossible, to tap into a telecommunication line to eavesdrop on a call. If this itself was not a deterrent, the legal system has evolved to protect the conversation occurring across a phone line and levy fines for malicious access and disruption to the telephone service. The Internet, on the other hand, is a wide-open system by design. Tapping into it is no more work than enabling an Internet Protocol (IP) transceiver to go into promiscuous mode and sniff all the packets crossing the transport. The same level of legal scrutiny afforded to the telephone system has not yet made its way to the Internet. Another rather subtle reason for more security in the telecommunications system has been how its protocols have evolved. Telephone networks have traditionally been environments where the inner workings of the protocols and services, although not entirely secret, were not subject to as much public access and scrutiny as Internet protocols have been. Consequently, the number of people attempting to understand and implement these protocols, and indeed to mount malicious attacks, has been much less than the Internet equivalent. Thus, we derive a third requirement of the telecommunications SOA: to provide security in a manner conducive to the Internet.

Closely related to security is authentication. When a telephone subscriber makes a call, the network authoritatively knows the identity of the subscriber (because in the telecommunications network, the service provider owns the network and the subscriber data). Consequently, subscribers of the telecommunications network have learned to trust the content that flows over the telephone network. Services provided by the telephone network — call forwarding, caller ID, etc. — need not be further authorized or authenticated. The telephone service provider is the final arbiter on the authenticity of the service on that particular network. This is not the case on the Internet, where the provider of the transport (the network) is distinct from the provider of the content. The authentication problem on the Internet is made worse by the ease of mining new identities and the lack of a central trusted arbiter that can be used to rendezvous two previously unknown users. Some means of authoritatively authenticating the communicating user agents is a final requirement for a telecommunications SOA.

0 0

Post a comment