The standard service node (SN) is a versatile system that has often been referred to as an intelligent network in a box. Indeed, the SN combines the functions of service control, circuit switching, and intelligent peripherals in one box. The ingenuity of the SN concept is manifested in the way the SN accesses the PSTN: As Figure 1 demonstrates, the SN is connected to the switched network through a local (or toll, or wireless) switch as the ISDN endpoint [versus the SS No. 7 endpoint, such as a service control point (SCP)]. Because of that, the SN—even when it is part of the PSTN—behaves as an edge-of-the-network entity. As such, it needs no triggers provisioned; nor do the switches need to do anything more than straightforward call termination in order to pass control of the call to the SN. Finally, the edge position of the SN makes it a natural gateway to the Internet.
Later in this section, we will review examples of using the SN for supporting PSTN and Internet service interworking, but now we should emphasize another role of the SN—that of a pure intelligent peripheral. Although most digital switches now have built-in intelligent peripherals as part of their standard capabilities (for example, conversion from text to speech and vice versa), there are still switches that either do not have such capabilities or require for some calls certain rare and expensive additional capabilities that are implemented only in specialized intelligent peripherals. The IN standards specify the protocol necessary for accessing remote intelligent peripherals. This protocol (between the specialized resource and service control functions) is a part of the Intelligent Network Application Part (INAP) protocol. When the SN has to perform purely the function of an intelligent peripheral, it must be able to connect to the SCP through SS No. 7 and support the relevant subset of INAP. Figure 2 reflects this point.
Figure 2: The SN as an intelligent peripheral.
The essential features supported by SNs include voice dialing, personal number, audio calling name delivery, paging message delivery, voice announcement/digit collection, interactive voice response, text-to-speech conversion, and voice/fax mailbox (a feature of universal messaging). Various service features can be mixed and matched in the SN to suit particular market demands. For example, one might install features like voice/fax mailbox and personal number to target a business district, and—in the same SN—voice dialing and voice mailbox to target residential areas. All told, the capabilities of the SN products are naturally derived from the fundamental capabilities of its three components:
1. Switching. Capabilities include (1) establishment of a call leg from the SN to any party (by requesting a connection from the PSTN or responding to a request from the PSTN) and joining the legs into a multiparty call (although it is two-party calls that dominate the services scene) and (2) rearranging the legs as needed [for example, tearing down connections between parties A and B, releasing (disconnecting) B, and connecting A with C]. Note that a party to a call may be a device (specialized resource) within the SN. The legs are established using access protocols (typically, Q.931). Although this is not explicitly required by the IN standards, the most sophisticated products have the SS No. 7 ISDN User Part (ISUP) protocol, which allows the SN switching module to establish trunks to the switches.
2. Specialized resources. Capabilities include playing announcements and collecting digits (found in all products); converting text to speech; recognizing speech (in high-end products) and converting it to text; converting received faxes to text (using the optical character recognition technologies available in high-end products); and performing other intramedia conversions by chaining the preceding functions (that is, converting fax to speech by first converting it to text and then converting the text to speech). Another set of capabilities deals with communicating the results of conversions. Those that end up in speech are naturally communicated over the voice lines; thus, the resources involved must be able to act as endpoints in telephone calls. Conversion to text (or encoded digits, as is the case with digit collection) is carried via data communications (to the SCP via SS No. 7) or to an IP host (via the Internet or a private IP network).
3. Service control. Capabilities are those of a general-purpose computer. To this end, the switching and specialized resources can be considered the peripheral input/output (I/O) devices of this computer. It is the service logic (that is, the program that implements a particular service) that makes the capabilities of service control devices available to end users. Service control is software function; service logic is software that is highly specialized to deal with the IN-supported services. The software is developed within the framework of a service creation environment (SCE). The output of the SCE is provisioned by the IN service management systems (SMSs) to all IN entities in the network. The SCE platforms typically run on the same machines that execute SMSs, but they may also run on separate processors. Because of their universal role (they are applicable to all IN physical entities), the SMS processors and software are usually sold separately from SNs. The SNs, however, must support the interface to service management, as reflected in Figure 3, which presents the full set of the SN interconnection with other network entities.
Figure 3: Connection to service creation environment and service management system.
As we mentioned in the section on IN standards, the ITU-T standard for service creation is rather schematic in that only general building block capabilities have been standardized. Consequently, while most products are fully compliant with the standard, the compliance itself manifests only support of the capabilities rather than interoperability of SCEs and SNs [or service control points (SCPs)] from different vendors—in general, they are not interoperable. An important question to ask when evaluating a specific vendor is whether the SCE that interworks with the SN is the same as the one that interworks with the SCP. If the answer is yes, then the service logic developed for (and tested on) the SN can also run on the SCPs; otherwise, service development and maintenance are likely to be a nightmare. Finally, as in the case of the switching module, some implementations support the INAP interface to switches. This interface is not required by a standard. Its introduction, of course, makes the SN a full-blown SCP. This, paired with the standard SN capabilities, makes an augmented SN into a powerful and versatile IN engine.
SNs have been employed in PSTN-Internet interworking since 1995. We refer to the type of interworking where the PSTN services are accessed and, in part, controlled from the Internet, while the voice endpoints are connected to the PSTN. The PINT services and a notification version of Internet call-waiting (ICW) service are typical examples of services easily supported by SNs.
Consider the operation of the click-to-call-back service described earlier (This example is illustrated in Figure 4.) Party A decides to receive a call from a sales agent (as offered on the Web page that A is presently looking at) and clicks on an appropriate button. (Without loss of generality, we can assume that A has already registered with the service provider and thus can be properly authenticated.) The Internet carries the request to the Web server B, which generates a corresponding request to the service node C. The request results in the execution of C’s service logic responsible for this particular service. As directed by the service logic, C, which has the ISDN basic rate interface (BRI) connection in this particular example to a local switch, first creates call leg 1 to the sales agent F, then call leg 2 to A, and finally merges these two legs in a two-party call: Now A and F are connected. The service management system is responsible for (1) passing the service-creation-environment-developed service logic to the service node and (2) provisioning the service-related parameters to both the Web server and the service node.
Figure 4: Operation of the click-to-call-back service.
Now, click-to-call-back service could be further augmented to the full function of a call center. The service node could, for example, select agent F based on the time of day, day of week, agent F’s availability and, if available, load relative to other available agents, and so on. For a report on relevant implementation experiences, see RFC 2458. A service like click-to-call-back is in fact a service feature that can be used as a building block to develop other services. Recently, there has been much interest in applying the Web business model (free access to customers subsidized by advertisers) to basic telephony service. Several telephone companies have tried a service offering a free-of-charge telephone call for customers who agreed to listen to several minutes of advertisements. This rather remarkable idea seemed to work, although advertisers complained that the purely audio commercial advertisements were not quite effective. Another problem with the advertisement was that end users had no control over (and, more importantly, no ability to request) the types of advertised information.
With the click-to-call-back feature in place, however, the creative possibilities of improving the original service are endless. To begin with, end users can register on the Web and at the same time indicate what types of products they are interested in. Thus, user profiles can be created. (With the help of the service management systems, these profiles can be distributed to all service nodes in the network.) The actual service then could contain an interactive video presentation delivered from the Web server, possibly combined and synchronized with the audio presentation delivered by a specialized resource of the service node. At the end of the presentation, the service node would create the call in exactly the same manner as with click-to-call-back.
As far as hardware is concerned, the SNs typically occupy one cabinet. They are powered by one or more fast CPUs and hard drives with high capacity. As with all other units of this type, one to six RS-232 ports (for example, for console support) and a 10/100-MB LAN port are present. A tape drive (which, in some cases, serves as a more efficient means of transferring the SMS output than an optional X.25-based interface) is invariably present, and so is firmware, which supports hardware sanity monitoring and the following alarms: over voltage, over temperature, and fan failure detection. The SS No. 7 and X.25 ports are usually optional.
Typically, the media service circuits and network interface come as enhanced industry system architecture (EISA) cards plugged into appropriate buses [such as a pulse-code modulation (PCM) bus]. The number of slots differs from 10 to over 100. Initially, large products (with over 100 slots) were popular, but recently the industry has set the requirement for an order of magnitude smaller (often called compact) SNs. (This requirement is quite reasonable: In diverse telecommunications networks it makes more sense to place more smaller and cheaper SNs in more places.) Different cards support different numbers of voice ports, T1 or E1 trunks, and so on, and configurations naturally differ among the products offered in and outside of the United States.
On average, a compact SN can terminate about 300 voice lines, all of which can be simultaneously married to the same number of resource circuits (text-to-speech and digit collectors). The supported resources can play and record voice (using the 32-kbps PCM format); detect dual-tone-multi-frequency (DTMF) and multifrequency (MF) tones; generate standard tones (busy, dial, audible, reorder, and receiver off hook); recognize digits pronounced in English, Italian, Spanish, German, Dutch, and French; and synthesize voice (both male and female) from text. Advanced products are also equipped with the grammar-based automatic speech recognition (ASR) capable of recognizing customer-defined names (for example, “Call Mom!”) and user-trainable entries. Fax capabilities include Group 3 fax record and transmission, ASCII-to-fax conversion, and fax store and forward. The conferencing control (usually performed by one card) parameters vary from one vendor to another; advanced products support close to 100 conferences with a maximum of 256 conference participants.
The software platforms, including choices of operating systems, vary among vendors. Some solutions include support of real-time databases, which we consider an essential feature. Overall, it is the programmability (rather than one or another internal software solution) that is essential for this particular product: The easier it is to create or change a service, the faster the service can be delivered. To this end, it is important to ask a question: Who is the user really involved with programming the services? As far as SNs are concerned, a number of parameters (called recent change data) should be changeable by service subscribers. In the very near future, this change will be done via the Internet, but for now it is generally done with the help of the SMS; nevertheless, some products provide access to the SNs themselves for the purposes of administration. Similarly, customization (that is, modification of the high-level service logic programs) can also be done directly on the SN in some cases. Customization is straightforward when it is programmed via a graphical user interface with the use of a palette of service-independent building blocks (SIBs), each of which implements, at this level, an atomic capability (play an announcement, put a call on queue, merge call legs, and so on), and which are connected into graphs representing the logic of a program.
The creation of the original service logic programs must be done in the SCE, which in most product offerings is not part of the SN. As mentioned before, there is currently no service creation standard that would allow interworking of an SCE from one vendor and SNs (or SCPs) from another. Thus, your choice of an SN provider should coincide with that of the SCE; conversely, the convenience and versatility of service creation is an important factor in choosing the SN. Service-independent building blocks (SIBs) were standardized by ITU-T only for the purpose of modeling; however, the industry picked up on the idea and many vendors have provided SIB-like palettes with which one can quickly develop services by simply building decision trees (more precisely, graphs) simply by mixing and matching appropriate SIBs (such as queue, play announcement, collect digits, and so forth). Thus, with SIBs, a service designer could build and test a service in no time without much help from an expert programmer whose services would be required if the work needed to be done from scratch. It is fair to say then that the support of the SIB-like graphical user interface has proven to be an essential programmability feature.
Another issue to consider is other programming levels available in products. The service creation platforms of advanced products offer several layers of programming, in increasing complexity, of which the graphical user interface is the first. The second layer typically includes more complex (and, therefore, more versatile) specification tools such as state machines [for example, the ITU-T Specification and Description Language (SDL)], and the third layer supports programming with the high-level systems programming languages (for example, C++). No standard format exists for the output of service creation environment. In some cases it is direct object code in the native machine language of the SN or SCP; in others it is a script to be interpreted by a service control process; and there are cases in which it is a combination of both.
No comments:
Post a Comment