Estimation of the Effects of non-in Traffic on IN Service Control Point Congestion Control Performance

Transcription

1 SCHOOL OF ELECTRONIC ENGINEERING Internal Technical Report Estimation of the Effects of non-in Traffic on IN Service Control Point Congestion Control Performance F. Lodge, T. Curran. Dublin City University, Ireland. 17th. November, Abstract This paper describes a simulation of an Intelligent Network (IN) which reflects the actual physical architecture of the network and models the information flows required between network entities in order to execute various IN services. An effective congestion control strategy is implemented with a suitable detection method at the Service Control Point (SCP) and Automatic Code Gapping (ACG) as a throttle mechanism in the Service Switching Points (SSPs). Non-IN traffic is then introduced to the network and the effects of this extra load at the switches on the performance of the congestion control strategy is estimated using SCP queue length, SCP throughput and user response delays as the relevant criteria. 1. Introduction The concept of the Intelligent Network was developed in order to allow users to create and maintain services quickly and easily and to provide all authorised users in the network with the ability to access any of the offered services. This objective is met through the creation of a

2 Service Control Point (SCP) - a point in the network where all service software resides and with which all Physical Entities (PEs) in the network may communicate in order to provide the required functionality. However, the architecture of the network is such that, to execute even the simplest service, many messages must be transmitted between PEs over the Signalling System Number 7 (SS7) network, resulting in large quantities of traffic. Although much research has gone into the areas of congestion and congestion control in switching systems, these issues have not yet been addressed in the field of IN. This paper focusses on the congestion which would inevitably result from all the interactions required to implement IN services. As in the general case, the aims in the development of an efficient congestion control strategy in the IN would be to successfully complete as many service requests for as many users as possible, while keeping response delays as low as possible. In this paper, an IN is simulated with service software for the televoting, freephone and callback services resident at the SCP. Three congestion control techniques are investigated to find which provides the optimal protection of the SCP while maximising SCP throughput and minimising the average response time of the system to the user. Finally, the performance of the selected control strategy is tested under realistic traffic loads with the SSPs in the network being subjected to a high traffic load of mixed IN and non-in call requests, with IN requests comprising only 35% of arriving calls. This emulates the actual load mix which would exist in a real IN, and therefore provides an accurate and realistic impression of the quality of the congestion control strategy. 1.1 The Intelligent Network The IN may exist either as an overlay to a telephone network (PSTN / ISDN etc.) in which case, all service requests are routed over the phone network to the SSP of the IN, or as part of the phone network, with SSP functionality installed in the telephone switches. In either case, the structure and operation of the IN is the same. The basic physical elements comprising the IN are: The Service Switching Point (SSP) - user access to service functionality is provided through the SSP, which handles call processing, detects service requests and provides connectivity to the SCP and other SSPs in the network. The SSP contains three discrete functions. The Call Control Agent Function (CCAF) provides user connectivity to the Call Control Function (CCF) which controls the progression of all calls. The CCF is responsible for handling both IN service requests and non-in calls. The CCF manages the setup, maintenance and teardown of non-in calls, and when it detects any service requests, it initiates service execution by passing control of the call to the SCP via the Service Switching Function (SSF). The SSF builds all messages for the SCP and interprets all commands received from there. The Service Control Point (SCP) - the Service Control Function (SCF) resides here and controls the execution of all service software, including the transmission of messages to the network database and Intelligent Peripherals and the interpretation of results from the same. The Service Data Point (SDP) - this is connected directly to the SCP and contains all network data relevant to the execution of services. The Service Data Function (SDF)

3 interprets SCF-generated requests, accesses data in the database and sends results back to the SCF. The Intelligent Peripheral (IP) - the IP is connected to the SSP and provides the functionality for interactions between the network and users i.e. the reading of announcements, collection of digits typed in by the user etc.. The Service Resource Function (SRF) resides here. All communications between SSPs and SCPs and between SCPs and IPs occur over an SS7 network using the TCAP part of the protocol. The PEs and their interconnections are shown in Figure 1 below. SCP SCF SDF SDP SS7 Network Signalling Channel SSF SSP CCAF CCF Other SSPs Transport Channel SRF IP Figure 1: Architecture of the Intelligent Network 1.2 Congestion Control Much research has been carried out in the area of congestion control with a large number of strategies being investigated and compared. Any congestion control strategy may be divided into two distinct parts - the detection method and the throttle mechanism. The detection method describes how overload situations are recognised and, when overload is detected, the throttle mechanism is put in place to counteract the problem. The principle detection methods which have been investigated for use in switching systems are Queue Length Control, Load Measure Control and Call Count Control (and variations thereof), the results of which were that, in general, Call Count Control proved to be the most effective (see [4]) at protecting a switch. However, the IN is a much more complex system containing multiple elements which must interact to provide the functionality of the system. The SCP is at the core of the network and must be protected at all costs, but due to the distributed nature of the functionality in the network, it cannot be assumed that results attributable to the above detection methods in a discrete switching system also apply in the realm of the IN. Therefore, it proves necessary to evaluate the usefulness of using both Queue Length and Call Count Controls at the SCP. Another method - Response Time

4 Control - was developed specifically for implementation in the IN and was also investigated in the model. As SCP processing time should be optimised in the execution of services, it would be wasteful to spend time rejecting calls here. Also, in general in congestion control, it is desirable to kill unwanted calls as near to the source as possible. Therefore, the throttle mechanism associated with the control strategy should be located in the SSPs of the IN. Some investigation has already been carried out on throttle mechanisms in the IN (see [1] and [2]) and the Automatic Code Gapping (ACG) throttle consistently provides the highest level of protection to the SCP and is therefore implemented in the simulation model. The operation of the ACG mechanism will be described in Section Modelling the IN The IN simulation was developed using OPNET (OPtimised Network Engineering Tools). Each PE was modelled as a queueing node which contained the required functionality. In order to describe how the system was designed, it is first necessary to show the interactions required between PEs to execute a service. 2.1 Decomposition of Services The best method of describing how a service decomposes into actions at PEs and information flows between PEs is to provide a simple example. Therefore, the breakdown of the interaction requirements for a simple Televoting service as implemented in the simulation is as follows: User Requests Televoting Service SSF/CCF SCF SRF SDF Analysed Info Connect to Resource Prompt and Collect User Info Collected User Info Update Data Update Confirmation Disconnect Fwd Connection Play Announcement Figure 2: Decomposition of Televoting Service

5 User goes offhook and dials the televoting number, The digits typed in by the user are collected and examined by the CCF, A service request is recognised by the CCF and call processing is suspended, The SSF builds an Analysed_Info message containing the dialled digits and sends it to the SCF via the SS7, The SCF creates a new instance of the Televoting Service Logic Program (SLP), The SLP Instance (SLPI) sends a message to the SSF requesting that a channel be opened between the user and the SRF, The SLPI sends a message to the SRF requesting that the relevant announcement be read and the digits keyed in by the user in response be collected, The SRF collects the resulting digits and passes them back to the SCF, The SCF sends a message to the SDF in order to update the televoting statistics, The SDF sends an acknowledgement, The SCF requests the SRF to play an acknowledgement announcement to the user, The SCF tells the SSF to disconnect the SRF from the user and to end the call. The SLPI then terminates. The SSF transfers the SCF's instructions to the CCF, which then terminates call processing. The information flows between functional entities as described above are shown in Figure 2. The other services implemented were decomposed into information flows in a similar manner. The information flow details from the SCP to other PEs may be summarised as shown in Table 1. Note that, for both freephone and callback services, service logic execution completion results in the establishment of a non-in call. Table 1: SCP Interactions Service IP Requests SDP Requests Freephone - 1 Callback 2 2 Televoting The Simulation Model The simulation model consists of one SCP, one SDP and two SSPs connected together as shown in Figure 3. The SCP is made up of four queues - one First-in-first-out (FIFO) queue acting as the central controller while each service logic program is represented by another queue which contains the required routing information for the service. The central controller is responsible for implementing the detection routines. The SDP is connected directly to the SCP and simply comprises one FIFO queue. An IP is integrated with each SSP - every IP request begins with a request to an SSP to open a channel between the IP and the user, before instructions are sent to the IP. Therefore, giving the SSP control over SRF execution simplifies the model without affecting the sequence of events involved in service processing. The SSP is made up of a number of queues - one each to represent the functionality of the CCF (FIFO), the SSF (FIFO with two subqueues - the first subqueue accepts all new call requests and the second is for service calls which have completed processing and require the establishment of a non-in call. The second subqueue is served with a higher priority than the

6 new calls in the first subqueue.) and the SRF (Erlang-C). Also included in the SSP is a bank of queues to deal with the exchange of messages between SSPs for dealing with non-in calls. SCP SDP SSF SSF SRF CCF non-in messages CCF SRF Generators Figure 3: The Simulation Model Each SSP also contains four ideal Poisson generators. Each generator creates requests of a particular type - namely freephone requests, callback requests, televoting requests and non-in calls. The operation of the SS7 network which, in reality, would be responsible for handling communications between PEs is not addressed in the model - modelling delays in the SS7 is a very complex task and was perceived to be outside the scope of this investigation. Therefore, all PEs are connected directly to each other, as shown in the diagram, and transmission delays are assumed to be negligible. 2.3 Measurement of User Delays User delays were measured by summing the delays for each request at each node on the route through the network in order to find the total delay for each request and calculating the average over all requests for each service type. However, the IP is implemented as an Erlang C model with the service time representing the time in service execution when the network is interacting with the user i.e. the user has received a response from the network even though the service has not yet completed. Therefore, the delay at the IP is discounted from the overall service delay. Note, therefore, that in services which require user interaction, the delays may appear quite high (to the order of 1-2 seconds), but the user has received a response from the network during that period.

7 3 Investigation of Congestion Control Strategies 3.1 Effects of Congestion on the IN Initially, the arrival rate of the non-in generator was set to zero, so that all traffic arriving at the SSPs was service related. The service request generators were set to ensure a steady load on the SCP and a good service traffic mix. The average delays to the user were initially measured under optimal network conditions i.e. the queue lengths at all nodes were at a steady state value and the system was processing as many requests as possible without becoming congested. These delays were thereafter used as the ideal network response times for comparison purposes. Once the ideal parameters for delay were established, the effects of an overload on the SCP were investigated by increasing the input traffic generated by the televoting generator. The effects of this overload on SCP queue lengths and average user delays was dramatic as shown in Figures 4a and 4b below. Figure 4a: Effects of Congestion on SCP Queue Length

8 Figure 4b: Effects of Congestion on User Delays 3.2 IN Congestion Control Strategies The next step was to put congestion control mechanisms in place. The performance of three detection methods was investigated by implementing them at the SCP and judging their effectiveness relative to SCP queue length, user response and throughput. The detection methods investigated were: Queue Length Control (QLC), which involves monitoring the queue length at the SCP and signifying an overload when a predefined maximum length is exceeded. Call Count Control (CCC), which is implemented at the input of the SCP and counts the number of new service requests arriving at the SCP within successive time intervals and signifies an overload when a previously specified maximum limit is exceeded. CCC may, if desired, be refined further to count the arrivals of each service separately, so that if an overload occurs on one service only, the SCP will recognise this and can specify that a throttle should be placed on the congested service only. This would improve the fairness of the congestion control strategy. Response Time Control (RTC), in which the average delay in responding to a user request is monitored over a predetermined interval and, when the permissible limit is exceeded, the existence of an overload is notified. The RTC algorithm is implemented at the output queue of the SCP. The measured delay includes delays at the SCP, IP, SDP and SSP. Therefore, this detection method has an advantage over CCC in that if the IP or SDP becomes overloaded, this will register in the SCP, as the total delays of requests will be effected by the delays at these PEs. On the other hand, as the response time for each service type varies according to the requirements which the service places on the system, the average delay must be measured separately for each service request type, which makes RTC more complex to implement that CCC. However, this complexity also means that extending the control strategy so that it can throttle only one service is a very simple task. For all detection methods, the level of overload is derived from the amount by which the boundary level is exceeded. In the simulation, six overload levels are defined at the SCP. For each level, a gap interval value is specified. At the end of the monitoring period within the SCP, if an overload is detected at the SCP, its severity is estimated and an overload level assigned. An ACG request is formulated and transmitted to the SSP. These request contains a

9 gap duration (length of time for which ACG is to be executed) level and a gap interval (interval for which all queries to the SCP should be blocked after each accepted call) level selected by the SCP. Call Accepted Calls Rejected Gap Interval Gap Duration Figure 5: The ACG Throttle Mechanism When the SSP receives the ACG request, the gap interval time and gap duration associated with the overload level are evaluated and timers are initialised for each. The next service request to arrive will be accepted and the interval timer set. Until this timer expires, all further arriving calls will be unconditionally blocked. After the gap interval has elapsed, the first call to arrive is accepted and serviced and the gap interval timer is reinitialised. This call restricting procedure continues until the gap duration has expired [3]. Once the relevant controls were put in place in the model, the effects of QLC, CCC and RTC on network operation were evaluated for various severities of overload and with various traffic mixes. The average user delay for each service type and the number of rejected calls (as a percentage of total offered traffic) were monitored for each control type. The results will be presented in the next section. 3.3 Congestion Results When the network was subjected to a traffic load which was, on average, below congestion levels, but was prone to bursts of heavy traffic, QLC was found to be superior to both CCC and QLC in dealing with the problem. This is due to the fact that QLC is a dynamic detection method, and responds instantaneously to any sudden increases in traffic load by rejecting the calls which cause overload. On the other hand, both CCC and RTC monitor traffic over a time interval, so that, by the time the overload has been detected, the calls which caused the overload have already been accepted by the SCP and it therefore takes both longer to deal with the overload situation and causes an unnecessarily high number of calls to be rejected. However, when the network was supplied with consistently high traffic loads, it was found that [5] CCC and RTC both were far superior to QLC as, under heavy loads, QLC rejected high proportions of offered traffic, without ever reducing the overload situation. Therefore, all further comparisons of results under consistently heavy overload conditions will be carried out between RTC and CCC only. On analysis of the graphical results of the simulations (see Figure 6 for service delays and Table 2 for the percentage of calls rejected), it may be seen that RTC is consistently more

10 effective at reducing user delays during congestion situations. On the other hand, as CCC takes place at the input to the SCP while RTC occurs at the output, CCC responds faster to the onset of congestion - an increase in offered traffic is detected almost immediately and a throttle put in place. For RTC, the SCP is already congested by the time detection occurs and more extreme control measures must be taken in order to deal with the situation. Therefore, when periods of congestion occur sporadically, more calls are rejected when using RTC than when using CCC. At higher overload levels, when the number of offered calls to the SCP is consistently too high, so that a throttle must be constantly maintained, the speed at which the system reacts to the onset of congestion is no longer an issue and both strategies are seen to result in the same percentage of rejected calls. Figure 6: Average User Delays Under Congestion Table 2: Rejected Calls (as %age of Total Offered) \ SCP Load Strategy \ Call Count Control 7% 23% 57% Response Time Control 18% 36% 57% It may therefore be concluded that while RTC is better at protecting network elements from the detrimental effects of congestion, it is slow to respond to bursts of high traffic. CCC, while not as effective as RTC at reducing delays, still provides good results and copes very well with instances of high bursty traffic. Therefore, CCC was chosen as the being consistently the best detection method for protecting the SCP from overload. The effects of CCC on traffic levels of 1.0, 1.2 and 1.33 times the maximum acceptable load levels are shown in Figures 7a and 7b below. Figure 7a shows the mean SCP queue length for each overload level, while Figure 7b shows the average user delays for the televoting and freephone services for each overload level.

11 Figure 7a: SCP Queue Lengths Under Various Overload Conditions Figure 7b: Service Delays Under Various Overload Conditions A comparison between the ideal throughput for any control scheme and the actual throughput for CCC is shown in Figure 8 below. As can be seen in the graph, the results given by CCC are quite close to the ideal. It may therefore be concluded that CCC is very effective at maximising SCP throughput while protecting it from being congested.

12 Figure 8: Network Throughput under Congestion Control 4. Estimation of the Effects of non-in Traffic on Congestion Control Performance The final step involves the introduction of non-in calls into the network and the estimation of their affect on network performance. The generators in both SSPs were set so that the traffic ratio of non-in calls to service requests was 65:35, as would be the case in a real telephone network. The effects of these calls on the SCP queue length and service delays was monitored at overload levels of 1.0, 1.2 and 1.33 times maximum acceptable service load. The results may be seen in Figures 9a and 9b, where 9a shows the delay for users of the televoting and freephone services with and without non-in calls and 9b shows the variation in mean SCP queue length caused by the introduction of non-in calls.

13 Figure 9a: Service Delays with and without non-in Calls Figure 9b: SCP Queue Length with and without non-in Calls Note that when non-in calls are introduced to the system, the initial results seem superior to the case when all calls are service related. SCP queue length is lower as are the service delays. However, as time progresses, the situation worsens until eventually, the SCP queue lengths and the service delays are longer than when no non-in calls were present. The reasons for this are as follows. When the simulation begins, the number of non-in calls arriving at the SSPs is considerably greater than the number of service requests but the time required to process the calls is the same. Therefore, all service related calls are delayed by the presence of the non-in calls in the queue. This means that initially the SCP queue length is maintained quite low. In other words, the non-in calls in the SSPs act as a delaying buffer to the SCP. This affects the service delays in that, as the SCP queue length is low, both new arrivals and responses from the SDP and IP do not have to wait as long for service by the SCP processor and the overall delays experienced by the requests is lower. However, as time passes, the buffering effect of the non-in calls diminishes and the SCP queue length rises which in turn causes the service delays to increase accordingly. Therefore, in the long term, once the initial beneficial effects of introducing non-in calls into the network have vanished, the performance of the CCC strategy at the SCP is detrimentally affected, with SCP queue lengths and service delays longer than those which existed when only service related calls

14 were being handled. However, the CCC strategy is not affected by the non-in calls in that it remains consistently effective at ensuring the maximum possible throughput at the SCP. 6. Conclusions There are a number of conclusions which may be drawn about the results as discovered in the model. The first, and most obvious, is that it is vital to take into account the effects of non- IN traffic at the SSPs when investigating the performance of congestion control strategies at protecting the SCP while minimising user delays. CCC seems to be the best detection method for protecting the SCP when the network is subjected to service related calls only, as it rejects fewer calls than RTC while providing user delays which are only slightly greater than RTC. However, when non-in calls are introduced, the result is a small but significant increase in user delays. This would imply that the best possible strategy for controlling congestion in the IN would combine the advantages of CCC - speed of response and maximum possible throughput under overload conditions - with the advantages of RTC, which minimises the delays at the SCP, SDP and IPs (thus ensuring that they do not individually become overloaded) so that the lowest possible user delays can be offered. It is therefore recommended that future research in the area of IN congestion control should focus on developing a strategy which uses CCC in conjunction with RTC in order to maximise service handling capabilities while maintaining user delays as low as possible. References [1] N. Tsolas, G. Abdo and R. Bottheim, "Performance and Overload Considerations when Introducing IN into an Existing Network", ITC-13, North Holland, 1991, pp [2] X. H. Pham, "Congestion Control for Intelligent Networks", Computer Networks and ISDN Systems, Volume 26, No. 5, January [3] Bellcore, "Advanced Intelligent Network (AIN) 0.1 Switching Systems Generic Requirements", August [4] U. Korner, "Overload Control of SPC Systems", International Zurich Seminar on Digital Communications - Intelligent Networks and Their Applications, March [5] F. Lodge, T. Curran, M. Gulyani, A. Newcombe, "Intelligent Network Congestion Control Strategies and their Impact on User-Level Quality of Service", Proceedings of the Australian Telecommunication Networks & Applications Conference, Melbourne, December 1994.