Project Topics
Get Complete Project Material File(s) Now! »
Increased Service Velocity at Low Cost
To enable market driven, rapid introduction of new services, with a direct responsiveness to ever-changing customer needs. The new services should be ‘optimized’ for low costs.
Enable Vendor-Independent Deployment
Ensure services, which are independent of vendors’ equipment and be able to work over multi-vendor equipment. This needs a high level of flexibility in the network in terms of hardware and software. The IN architecture should be designed such that integration within and among the software and hardware, possibly from different vendors, is possible.
Evolve from Existing Networks
The new network must inter-work and evolve from the existing network, since it would be very expensive to replace the existing networks.
What is an Intelligent Network (IN)
The Intelligent Network is more than just network architecture. An Intelligent Network is a service-independent telecommunications’ network [5]. In an Intelligent Network, intelligence is taken out of the switch and placed in computer nodes that are distributed throughout the network. It is a complete framework for the creation, provisioning and management of advanced communications services [6], in which the service logic for a call is located separately from the switching facilities, allowing services to be added or changed without having to redesign switching equipment. This provides the network operator with the means to develop and control services more efficiently and new capabilities can be rapidly introduced into the network. Once introduced, services could easily be customized to meet individual customers’ needs. According to Bell Atlantic, IN is a ‘service-specific’ architecture. That is, a certain portion of a dialled phone number, such as 800 or 900, triggers a request for a specific service.
IN has effectively put the destiny of incumbent carriers squarely in its own hands [6]. Distributing readily programmable intelligence across their networks and freed telecommunication service providers from their traditional dependence on switch manufacturers in the all-important provisioning of new AIN services. Software has had to be installed in far fewer locations, thanks to SS7s1 support of centralized intelligent nodes.
A later version of IN called Advanced Intelligent Network (AIN) introduces the idea of a ‘service-independent’ architecture in which a given part of a telephone number can be interpreted differently by different services depending on factors such as time of day, caller identity, and type of call. AIN makes it easy to add new services without having to install new phone equipment. For a more detailed understanding of IN and AIN, an interested reader is referred to [5], [6] and [7].
IN Architecture
Tsun-Chieh Chiang et al. [9] discusses that IN provides a framework to decouple service logic from switching nodes and make it easily accessible from other nodes within the network. In the physical plane of this framework, switching nodes are called Service Xwitching Points (SSP), while network nodes that host services are called Service Control Points (SCP). Call control and service switching functions are implemented within the SSP, while the service control functionalities are hosted by the SCP. Figure 2.4.1 (a) shows the physical architecture of an Intelligent Network.
An SSP implements connection management capabilities and supports a Signaling System 7 (SS7) signaling interface. IN defines standard call states and triggers2, that can be enabled to cause the SSP to suspend call processing and query an SCP for further instructions on how to treat the call. An SCP hosts IN services that are accessed by SSP, performs real- time database query processing, and enables the SSP to access other network resources such as Intelligent Peripherals (IP) as required during call processing.
The Intelligent Network architecture builds on a traditional network architecture while adding new elements. Amir-Ebrahimi et al. [8] discusses the six key elements of an Intelligent Network as discussed below. For more details about the physical architecture of the IN, please refer to [8] and [9].
Service Switching Points (SSP)
The SSP functionality is the key IN functionality of the switching system. An SSP switch is capable of detecting an IN service call, sending a signaling query to an SCP and responding to the responses/commands received from the SCP. The SCP, after analyzing the request, returns the appropriate control information to the SSP on how to process the call. This capability enables an IN end-office switch to interface with SCP databases using SS7 over Transaction Capabilities Application Part (TCAP) protocol.
Service Control Point (SCP)
The SCP has call control logic often with access to a co-resident database. It fields queries from the SSP, parses and processes them and provides the appropriate responses. It provides real time call processing logic for IN calls. It compares the information about the call provided in the query to the telco-defined data available for each service on the SCP to determine how the call should be treated (It does not matter to an SCP-based service whether the call originated from the Public Switched Telephone Network (PSTN) or an Internet endpoint. As long as the SCP gets the required information through a standard protocol (TCAP) in a predefined format, it will execute its service logic and return the results to the SSP). This is indicated to the SSP in the response message. Depending on this response, the SSP may either (i) route the call, (ii) forward to an announcement, or (iii) prompt the caller for collection of additional Dual-Tome Multi-Frequency (DTMF3) information.
Signal Transfer Point (STP)
Signal Transfer Points form the backbone of the Common Channel Signaling System 7 network. They are an integral part of the IN architecture and provide TCAP signaling between SSPs and SCPs.
Service Node (SN)
The Service Node provides an additional level of capabilities by providing a platform where IN calls can be forwarded to. These calls can access any of the existing services on the Service Node e.g. voice/fax mail or routing to another destination etc. Service Nodes can also be accessed by non-IN switches.
Service Creation Environment (SCE)
The SCE is a stand-alone product that provides a development environment for creating service applications and generating platform software for SCPs and SNs. It provides tools for writing and editing of Service Packages and compiling them for use on the network elements. The SCE enables the network provider to develop, test, deploy, and modify Intelligent Network services for the SCP and SN in a rapid and flexible manner.
Four Multi-Agent Architectures for IN Load Control
The four Multi-Agent architectures classified in terms of ‘synchronization’ and ‘distributedness’ are,
Centralized Auction and Centralized Leaky Bucket Architectures are centralized. The Hierarchical Distributed Auction and the Mobile Broker Architectures are distributed. In aspect of resource allocation, Centralized Auction and Hierarchical Distributed Auction Architecture are synchronized. Centralized Leaky Bucket Architecture and Mobile Broker Architecture are asynchronous By distributedness, it is meant to what degree the control over the system is distributed. Two possible extremes could be, peer-to-peer autonomous agent systems and threaded systems (which all control is dependant on single agent) [4].
The degree of synchronization is a measure of how the execution of agents, interrelate with each other. There are highly ‘sophisticated’ agents, which interact only at special instances of time. Yet there are systems in which agents interact continuously, and are ‘asynchronous’ in nature [4]. Below is a short description of the four Multi-Agent architectures for IN load control.
The Centralized-Auction (CA) Architecture
The Centralized-Auction architecture is centralized and synchronous. Each SCP has a corresponding Quantifier, which supervises the SCP, keeping track of its processing capacity, its current load & status. On the other hand, each SSP has a corresponding Allocator which monitors the experienced load at its respective SSP and manages to buy the correct amount of SCP processing resources, an SSP node is expected to require. Figure 3.2.1 represents a diagrammatic representation of a typical Centralized-Auction Architecture.
In the CA architecture, all the Allocators maintain a pool of tokens (each token corresponds to an SCP’s processing of a service request). These tokens are sold by the Quantifiers (on behalf of the respective SCPs) to the Allocators (acting on behalf of the respective SSPs) in every auction. These auctions are carried out by the Distributors, typically every 10 seconds, where the Quantifiers sell the SCP processing capacity to the Allocators, who send in their bids to buy the processing power offered by the Quantifiers. When an SSP accepts a service request from a subscriber, a token is removed from the pool of available tokens of the respective SSP. To serve a request, a direct connection between an SSP and an SCP is established. In the absence of any tokens, in a pool, an SSP would not accept any service requests.
In situations where the demand for the services goes beyond the available resources, there is a probability that SSPs would run out of the tokens, just after an auction, even when there is considerable time left in the next auction. Hence a ‘Rejection Probability’ is calculated so that the remaining tokens are equally distributed over time, between two auctions (see ‘Percent Thinning’ in the next section) in network overload situations.
As the load in the Intelligent Network is varying, it is unwise to utilise the IN resources at a maximum i.e. 100%. The reason being that in overload situations there would be no spare resources left over for emergency calls. The optimal solution should aim to utilise the system resources to a level below the system’s total capacity, referred to as the ‘Target Load’. Typically the Target load is set to 90%, which means that the load control algorithm should ensure that the total load on the system resources should not exceed the Target Load, i.e. 90% of the total available capacity. This is done by rejecting service requests, when the Offered Load exceeds the Target Load.
The Centralized Auction architecture originally proposed and implemented by Arvidsson et al. [1] was designed to maximize profits (also called Profit Optimization) for the Network Owner by favouring the services that result in higher profits. Which means that in network overload situations, the SSPs would reject the requests that would result in low profits, over high profit services. However in the absence of such a mechanism, the main task of an auction would be reduced only to distribution of SCP processing power to all SSPs, in accordance with the network load requirements. Refer to Arvidsson et al. [1] for a detailed description on CA.
Table of contents :
ABSTRACT
ACKNOWLEDGEMENTS
1 INTRODUCTION
1.1 RESOURCES – A LIMITATION IN COMMUNICATION NETWORKS
1.2 INTELLIGENT NETWORK LOAD CONTROL PROBLEM
1.3 SCALABILITY
1.4 THE RESEARCH QUESTION
1.5 OUTLINE OF THE THESIS
2 INTELLIGENT NETWORKS
2.1 EVOLUTION OF INTELLIGENT NETWORK
2.2 THE OBJECTIVES
2.2.1 Broadened Range of Services
2.2.2 Increased Service Velocity at Low Cost
2.2.3 Enable Vendor-Independent Deployment
2.2.4 Evolve from Existing Networks
2.3 WHAT IS AN INTELLIGENT NETWORK (IN)
2.4 IN ARCHITECTURE
2.4.1 Service Switching Points (SSP)
2.4.2 Service Control Point (SCP)
2.4.3 Signal Transfer Point (STP)
2.4.4 Service Node (SN)
2.4.5 Service Creation Environment (SCE)
2.4.6 Service Management System (SMS)
2.5 INTELLIGENT NETWORK SERVICES
2.6 THE FUTURE OF INTELLIGENT NETWORKS
3 AGENT-BASED APPROACHES TO IN LOAD CONTROL
3.1 THE AGENT TYPES
3.1.1 Allocators
3.1.2 Quantifiers
3.1.3 Distributors
3.2 FOUR MULTI-AGENT ARCHITECTURES FOR IN LOAD CONTROL
3.2.1 The Centralized-Auction (CA) Architecture
3.2.2 The Hierarchically Distributed Auction (HA) Architecture
3.2.3 The Centralized Leaky Bucket (CLB) Architecture
3.2.4 The Mobile Broker (MB) Architecture
4 SCALABILITY, THE ATTRIBUTES
4.1 UTILIZATION OF RESOURCES
4.2 COMMUNICATION DELAYS
4.2.1 Responsiveness
4.2.2 Request Processing Delays
4.2.3 Messaging Delays
4.3 CALL ACCEPT/REJECT RATES
4.4 COMMUNICATION OVERHEAD
4.5 COMPUTATIONAL OVERHEAD
4.6 LOAD BALANCING
4.7 REACTIVITY
5 SIMULATION PRECONDITIONS & SETTINGS
5.1 SIMULATION PRECONDITIONS
5.1.1 General Network Configuration
5.1.2 Prediction of the Offered Load
5.1.3 Architecture Specific Configurations
5.2 TABULATION OF RESULTS
5.3 SIMULATION RUNS
6 THE ANALYSIS
6.1 UTILIZATION OF RESOURCES
6.2 COMMUNICATION DELAYS
6.2.1 Responsiveness
6.2.2 Request Processing Delays
6.2.3 Messaging Delays
6.3 CALL ACCEPT/REJECT RATES
6.4 OVERHEAD COMMUNICATION
6.5 OVERHEAD COMPUTATIONS
6.6 LOAD BALANCING
6.7 REACTIVITY
6.7.1 Overload Control
7 CONCLUSIONS AND FUTURE WORK
REFERENCES
