IFTN Features and Functions

There is no standard level of IFTN feature/function transparency within the PBX industry. Some PBXs support a very high percentage of features and functions across multiple networked systems, up to 90 percent of the total generic software program, and some support less than 50 percent. Almost all PBX system IFTN options support the following basic feature/functions:

• Basic calling with the use of a flexible dialing plan (typically four or five digits)

• Voice terminal display information (calling party/called party name and number, call redirection information)

• Call forwarding services

• Call transfer

• Call conferencing

• Automatic callback

• Bridged call appearance

• Message waiting indication

• Trunk release

• Network-wide attendant services

• Network-wide CDR

An important category of features supported by only a few IFTN solutions is ACD. For example, all 55 of the identifiable NEAX 2400 IPX ACD features are available with Fusion CCS. The NEC ACD Agent Anywhere option is an intelligent network of multiple ACD systems using Fusion CCS links. ACD nodes can communicate with each other and pass and interpret signaling, caller ID, call prompt, and database information across the network. Intelligent interflow routing of callers between nodes improves customer service levels, balances traffic load, and optimizes agent productivity. Fusion CCS also supports centralized management reporting and supervisor workstation data screens. A multiple system ACD network has built-in redundancy to reduce system down time and increase customer satisfaction.

The Agent Anywhere option supports distributed ACD agents behind switch nodes remote from a centralized ACD processor node. ACD agents can be deployed anywhere within a Fusion CCS network, with the only restriction being that the remote switch node be directly linked, (no pass through signaling), to the control switch node. Agent Anywhere can be implemented when using internal or external ACD processing and software options. The Fusion CCS solution supports decentralized agents assigned to the same call split across multiple nodes. Incoming calls to the central control node can be routed to available agents in remote nodes if all agents are busy at the central location. For configu- rations with local incoming trunking at remote node locations, calls can be queued at the central control node location when no remote agents are available.

Many customers’ ACD-based call center systems include a CTI application server. A centralized CTI application server capable of supporting more than one PBX/ACD switch node is less costly and easier to manage and maintain than application servers at each customer location. The NEC Fusion CCS option supports a centralized CTI application server for ACD systems. Another good example of a centralized application server solution used within an IFTN configuration is the Siemens HiPath Allserve 150. A centralized Windows NT application server can support a network of one to four Siemens Hicom 150H systems networked with the Siemens CorNet option implemented over an IP LAN/WAN. The applications, run on a single server for all networked PBXs, include messaging, call center, personal call manager, and call accounting.

Perhaps the most important transparent system operations are management and control from a centralized application server. A central database for all Hicom 150H switch nodes resides in the application server. The centralized server provides one access point to administer and maintain each system. Station move/add/change transactions are implemented as if there were a single system, not multiple switch nodes. A single management or maintenance command can be applied to all switch nodes across the network, instead of inputting individual changes to individual systems. Centralized management system capabilities for all move, add, and change procedures is an important IFTN capability that is not commonly supported by most traditional circuit switched PBX IFTN options but is supported by more of the newer client/server IP-PBX system designs, such as Cisco’s AVVID IP telephony system.

Shared applications resources for call center, messaging, and management operations are an important IFTN cost savings benefit. The first IFTN offerings were limited to shared VMS applications. One VMS supported station users across a network of PBX systems. One of the cost savings components is attributable to the lower price for a single, very large messaging system as opposed to the collective cost of several smaller systems with equal voice mailbox and storage capabilities. Another cost savings component is ongoing management and service. Maintaining one messaging system is less costly and more efficient than maintaining several systems. The same cost savings criteria can be attributed to other shared application resources in an IFTN configuration.

Intelligent Feature Transparent Network (IFTN)

AT&T’s original ETN offering evolved into DCS in 1982 when the U.S. Navy required a single communications system for its San Diego naval base operations, with a port capacity far greater than the parameter limitations of any single PBX system model available at the time. The AT&T solution was not to design an extremely large PBX system but to intelligently network multiple systems to provide the appearance of one system for most common internal station-to-station user operations. Originally known as the Defense Metropolitan Area Telecommunications System (DMATS), the AT&T Dimension PBX option was renamed the Distributed Communications System (DCS). The AT&T Dimension DCS option became very popular in a short period and forced competitors to develop IFTN offerings of their own. Among the other wellknown IFTN brand name options developed almost 20 years ago and still marketed today are Siemens CorNet, NEC CCIS (since enhanced to Fusion CCS), and Fujitsu FIPN.

An IFTN has the property of transparency with respect to all on-net calling, and many feature operations. Transparency is the ability of the system, from a station user’s perspective, to operate across multiple network nodes in the same way it does at the local node. This allows for a limited digit dialing plan for all on-net calls, thereby eliminating the need for PBX location codes and network extension numbers. All intercom calls are dialed with extension numbers corresponding directly to station user directory numbers.

An IFTN design is based on the ETN model, a hierarchical layer of switching systems interconnected using tie trunks. Direct links between each PBX network node are not required, but there are limitations on the number of transit nodes that can pass intelligent control signals between the originating and terminating nodes. The passing of call handling signals between network nodes is what distinguishes an IFTN from an ETN. Out-of-band common channel signaling techniques are used. Each manufacturer’s IFTN offering was based on a proprietary signaling and messaging scheme, thereby limiting the flexibility of the customer network design, although the competing suppliers have worked together during the past decade to develop industry standards for open inter-PBX networking solutions 

The idea behind an IFTN is to have the common control complexes of multiple PBX systems communicating with each other to transmit data, customer network information, and command messages for a single system image. Specific details concerning how each PBX system implements its proprietary IFTN service offering are not available. The first implementation of AT&T’s DCS offering was based on analog tie trunks and channel-associated private line data circuits for nodal transmission links. When T1-carrier circuit services became available, clear channel signaling techniques were used instead of dedicated data circuits, and analog tie trunks were replaced with voice communications transmission. Twenty-three 64-Kbps channels of the T1-carrier circuit were used as bearer voice communications channels, and one 64-Kbps channel was used for inter-PBX signaling and messaging.

When ISDN PRI services became available in the late 1980s, the B-channels were used for voice communications and the D-channel was used to transport the control information. The most common signaling method used for IFTN networks, based on ISDN PRI service circuit links, is a temporary signaling connection (TSC). A TSC provides a temporary signaling path through ISDN switches for exchanging information between users. There are two TSC types: call associated CA-TSC and non–call associated NCA-TSC.

A CA-TSC refers to a service for exchanging user information messages that are associated with an ISDN B-channel connection by the call reference value of the control data packets. An NCA-TSC is a connection not related to any ISDN B-channel connections. It is an administered virtual connection established for exchanging user information messages on the ISDN D-channel. Once the NCA-TSC has been administered and enabled, it will be active for an extended period. There are two NCA-TSC types: permanent and as needed. A permanent NCA-TSC will remain established while the system is operating. If the connection is lost, an attempt will be made to re-establish it. An as-needed NCA-TSC is established based on user request and the available of TSC facilities. The connection is dropped after a preset period of inactivity.

ISDN PRI transmission services are currently the most commonly used communications and signaling transport links for IFTNs. Some IFTN offerings, such as Siemens CorNet, can be supported only when using ISDN PRI service circuits for circuit switched connections. Most PBX IFTN options also can be implemented with virtual networking services supporting a TSC, such as AT&T’s service offering. Other network transmission solutions that support inter-PBX message signaling are ATM trunk carrier services and TCP/IP over a LAN/WAN infrastructure. ATM networking options include T1-carrier CES and TDM/PCM conversion to ATM cell format for transmission over an ATM WAN. An important advantage of the TCP/IP networking option is that dedicated point-to-point signaling links between PBX network nodes are not required because point-to-multipoint signaling is supported by TCP/IP. Tandem switch nodes, the basic network element of circuit switched IFTNs, are not required if IP trunk circuits are used to pass communications and control/message signaling between switch nodes. This eliminates the transit node (hop-though) limitation for control signaling between originating and terminating switch nodes. There are several other advantages to using a LAN/WAN infrastructure as the IFTN network backbone:

1. Reduced PSTN trunk carrier services in support of IFTN networking result in potentially significant cost savings. Using existing IP trunk circuits to carry IFTN voice traffic and signaling between switch nodes eliminates the need for dedicated private line and/or ISDN PRI digital trunk circuits. Fewer physical T1-carrier trunk circuits are needed to carry voice traffic over an IP network because VoIP transport uses voice encoding and compression algorithm standards.
   
   
2. PBX system hardware costs decrease because fewer port circuit cards and port cabinet carriers are required. A single IP trunk circuit card can support a greater number of physical IP-based trunk circuit equivalents at a lower cost than traditional TDM/PCM station/trunk port circuit cards.
3. Signaling support is to and from a single LAN-connected applications server across multiple PBX systems, instead of dedicated servers at each location.
   
   
4. Network management and maintenance operations are simpler because a single converged voice/data network, instead of dedicated networks, is used to transport voice and data communications. An added benefit is a reduction in human and equipment management support resources.