 |
|
|
The intelligent network (IN and AIN) has long been promoted as the future of wireline telecommunications. More recently, WIN (Wireless Intelligent Network) has been promoted as its futuristic equivalent for wireless communications. IN, AIN and WIN promise a future where switches are dumb and peripheral devices are smart, where switches need to be upgraded to support the intelligent network only once, and SCPs can be programmed on a whim by carrier personnel. Unfortunately, this dream cannot be realized. This is not to say that the intelligent network has no value, just that what IN promises, it cannot deliver, and what it delivers can also be provided by other standards. It is not that the Emperor has no clothes, it is that we are being told he is wearing a coronation robe and I just see coveralls.
The Intelligent Network concept is understandably seductive. Instead of switches processing services, they simply execute a vanilla call processing model, spiced with ‘triggers’ at various points where greater intelligence may be required. If a trigger is not armed, call processing simply flows around it, but if it is armed, call processing is halted, and a message is sent to a neighboring Service Control Point (SCP). The SCP analyzes the information that was transmitted and responds with information that is used to resume call processing.
A call to a 1-800 number is a good example. If 1-800-633-5514 is dialed, digit analysis recognizes the 1-800 trigger pattern and halts call processing. A message is sent to an SCP, which looks up the 1-800 number in a database and returns a regular directory number (e.g. 1-403-274-4749), along with other information such as the long distance carrier who handles that particular number. Call processing then continues as if the substituted directory number had been dialed.
The benefit of the Intelligent Network is touted to be that when a switch has a complete suite of triggers, service development will no longer be required by switch vendors. Instead, the correct triggers just have to be turned on by the carrier. Tripping the trigger will initiate a message to an SCP that has the right smarts. In a small fraction of cases, this goal can be achieved. The relatively new 1-888 toll-free numbers are a good example. Assuming a flexible digit analysis system on the switch, the pattern 1-888 could arm the same trigger as used for 1-800. This promised flexibility of the Intelligent Network and freedom from the stranglehold of their switch vendors is irresistible to carriers.
Unfortunately, outside of new services that are simple variants of existing services, there are a large number of different situations where the intelligent network cannot prevent the need for switch development. Either:
It is interesting to examine the success of the Intelligent Network in addressing the needs of a new network capability – Local Number Portability (LNP). If this new capability is viewed as a test of the intelligent network concept, can IN or WIN deliver?
A Local Number Portability trigger would superficially resemble a 1-800 style trigger. After all, the switch still sends one number to the SCP (the dialed phone number) and receives a different number in return (the ported-to destination switch). However, the triggering condition is much more complex than simple digit analysis, as the query should only be initiated when a local number is received by the switch with the first 6 digits matching a record in a switch-internal database (i.e. a block of numbers containing at least one ported subscriber). When the switch receives a response from the SCP for a ported phone number, it will contain a routing number (LRN). This number does not replace the dialed digits (as in a 1-800 query). It reflects a new separation of the dialed directory digits (that still uniquely identify the called party to the call) and the routing digits (that tell the telephone network how to get the call to the called party's new switch). So, the triggering condition has changed, and the handling of the response has changed. The challenge of eliminating switch development has not been met.
The approach of the wireless industry to LNP is instructive. While WIN (known as TIA PN-3661) is relatively close to completion for the original three features (publication is estimated late in 1998), it was decided to implement LNP queries with a new IS-41 message. The traditional IS-41 approach has always been to add new messages and new parameters to existing messages whenever a need is demonstrated, rather than the WIN approach of attempting to define a generic infrastructure. With Local Number Portability, this approach (specified in TIA PN-3980) was believed to be more practical. Implementing Local Number Portability within WIN would have required significant changes to the WIN document, and would have required vendors to not only implement the basic WIN infrastructure but also to still develop LNP-specific software. Not only that, any delays in the production of the basic WIN infrastructure would have delayed all the WIN features, including LNP.
Do not take my tirade so far to mean that I am against the concept of off-switch feature processing on an SCP. Rather, I believe there are many excellent reasons to use an SCP, even if the goal of eliminating switch development for new services is abandoned. One major reason is management of the service database. For many new services (e.g. 1-800, 1-900 and Local Number Portability), the database is huge and must be shared by many carriers. The SCP concept simplifies management of the database by reducing the number of copies of the data, while keeping throughput above an acceptable level. One database per switch would make access much faster, but would create a management nightmare, as well as increasing the costs of switches to support huge, redundant databases with rapidly changing contents. The case for an SCP with each new service must be judged on its own merits. If an SCP solution is chosen, carriers should not expect to avoid some switch development.
Accepting that the Intelligent Network cannot attain its stated goal makes the IN protocol look much more like the wireless IS-41 protocol. This protocol for wireless network signaling and coordination has long allowed disparate network elements to communicate efficiently. Although IS-41 does not have the pretensions of IN, it does (with Revision C, at least) have similar capabilities and, more importantly, supports the mobility management that IN is totally lacking. The major advancement of WIN over IS-41 will be the ability for wireless switches (MSCs) to communicate with multiple SCPs rather than just one (the HLR).
The hype over the Intelligent Network obscures the more mundane reality. Future features will require a partnership between switch vendors, SCP vendors and carriers. Services that will be implemented in a distributed fashion will be those where a switch-only design is simply not practical – and the glue in wireless networks will continue to be that old workhorse: IS-41. For wireline systems, IN will simply be used as a protocol that enables wireline switches to move some service logic offboard in a switch-SCP partnership, not magic that will eliminate the need for ongoing switch feature development.
These developments will be clouded by misuse of the term ‘WIN’ that is already rampant today. Many people use WIN to refer to TIA’s existing IS-41 Revision C standard, not the PN-3661 project that is truly based on IN concepts. This promotes the misconception that WIN is available today, yet considering the publication schedule of PN-3661 (mid to late 1998) and the 12-24 month vendor development cycle, true WIN will not likely be commercially available until 1999.
© – Copyright