WO1999048306A1 - Simulator zur simulation eines intelligenten netzwerks - Google Patents

Simulator zur simulation eines intelligenten netzwerks Download PDF

Info

Publication number
WO1999048306A1
WO1999048306A1 PCT/EP1999/001141 EP9901141W WO9948306A1 WO 1999048306 A1 WO1999048306 A1 WO 1999048306A1 EP 9901141 W EP9901141 W EP 9901141W WO 9948306 A1 WO9948306 A1 WO 9948306A1
Authority
WO
WIPO (PCT)
Prior art keywords
simulator
scp
event
simulation
time
Prior art date
Application number
PCT/EP1999/001141
Other languages
English (en)
French (fr)
Inventor
Frank Steltner
Marian Trinkel
Hans Dieter Fischer
Berthold KRÖGER
Fritz-Jürgen REICH
Original Assignee
Deutsche Telekom Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Deutsche Telekom Ag filed Critical Deutsche Telekom Ag
Priority to EP99939863A priority Critical patent/EP1013109A1/de
Priority to US09/423,954 priority patent/US6650731B1/en
Priority to HU0400884A priority patent/HUP0400884A2/hu
Priority to CA002289515A priority patent/CA2289515A1/en
Priority to JP54644799A priority patent/JP2001526876A/ja
Publication of WO1999048306A1 publication Critical patent/WO1999048306A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0062—Provisions for network management
    • H04Q3/0091—Congestion or overload control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/36—Statistical metering, e.g. recording occasions when traffic exceeds capacity of trunks
    • H04M3/362—Traffic simulation

Definitions

  • the invention relates to a simulator for simulating an intelligent network, in particular for finding and analyzing weak points, for testing network configurations and / or control mechanisms, and for finding possibilities for increasing the performance of the network.
  • intelligent network stands worldwide for the concept of a network architecture valid for all telecommunication networks.
  • the core element of this concept is a software-defined, individual communication profile for customers of telecommunications services.
  • Important functions and data are centralized in the IN and are only provided in one or a few nodes. These functions and data relate, for example, to information on how a call with an IN-specific number should be handled depending on its place of origin, the dialed number, the time of day and / or other parameters, e.g. whether and to which network subscriber a call is transferred, whether and to which announcements a call should be switched or whether a call is only counted.
  • intelligent, branched database access from a plurality of service access points (SSP) to data and functions stored in one or a few central nodes (service control point, SCP) for service control is implemented.
  • SSP service access points
  • SCP central nodes
  • the intelligent network is a centralized network over the telephone network and provides intelligence for setting up and clearing down connections via the telephone network.
  • the interface between the telephone network and the intelligent network is formed by the SSPs, in which calls are received with IN-specific phone numbers and, after receiving the processing information, are processed further by the SCP in accordance with these instructions, for example are forwarded to a phone number communicated by the SCP.
  • the individual functional complexes are implemented in separate system levels. IN transport and switching functions are implemented in the SSP level (Service Switching Point), service control functions and administration of the service data in the SCP level (Service Control Point) and service management in the service
  • SMS Session Management system
  • SS7 system signaling system no. 7
  • STP or SRP service transfer or relay point
  • the STP or SRP is used for the switching and distribution (routing) of the messages in the central signaling channel between the SCP and the SSP.
  • STP or SRP can also serve as a gateway for messages that relate to the IN services of another network operator and must be processed by the SCP of another IN.
  • the routing criterion for an IN message is its global title; the STP / SRP level implements Global Title Translation (GTT).
  • GTT Global Title Translation
  • the SSP level has options for recognizing IN connections, e.g. based on the phone number, and to support. With these connections, information must be requested from an SCP for further connection establishment.
  • the SCP contains programs and the associated data for controlling the services. Furthermore, the SCP collects data on charging and statistical evaluations. Multiple SSPs access a central SCP.
  • the Service Management System which contains the administration of the IN services and IN components, is superior to the SCP.
  • Televotum The Televotum service enables the service subscriber to register the number of calls under his Televotum number.
  • a request is made to the SCP for every call, in a further variant the calls in the SSP are counted, with a request to the SCP for every kth call.
  • every TV call arriving in the IN system is registered.
  • 3 Every nth call is treated specially, for example after the registration is forwarded to a destination specified by the service subscriber. After registration, all other calls lead to an announcement that was also specified in the traffic management program by the service subscriber.
  • Freephone The Freephone service gives service users the opportunity to call the "service subscriber" free of charge. The entire fee is borne by the service subscriber.
  • Universal call number With the service universal call number it is possible that a service subscriber can be reached anywhere under a uniform, network-independent call number. Depending on the definition of the service subscriber, the charges for such connections can be raised by the caller alone or divided between the calling and called parties.
  • Tele-Info-Service enables callers to access the information offered by the service subscriber via their announcement devices or in direct dialogue.
  • the charges are charged to the caller and can be based on the connection-related
  • mobile radio networks are also intelligent networks.
  • the service subscriber has the possibility of specifying his service on the basis of further service features, e.g.
  • Call redirection If the selected subscriber does not answer or the number is busy, the call is either transferred to an announcement or to another number. This process can be repeated up to a specified number of attempts, otherwise the call is rejected.
  • Call restriction If the number of calls to a pull call number exceeds the one specified by the service subscriber within a period of time 4 Limitation, the excess calls are made to defined alternative destination numbers or announcements.
  • Time-dependent destination control The time of the call is checked against the periodic and / or temporary time windows. If no valid time window is found, the SCP leads the IN call to a standard message, otherwise the call branches or to the next service feature.
  • Origin-dependent destination control The network origin information is compared with the origin information stored in the traffic management program. If no match is found, the SCP leads the call to a standard advisory announcement, otherwise the system branches to the call destination or the next service feature.
  • the call distribution service feature allows the definition of individual quotas, according to which calls are distributed to different destinations.
  • the SSP acts as a fictitious communication participant.
  • the SSP supports network performance-related standard announcements and announcements that can be controlled as a call destination.
  • the individual announcements have a limited number of query places. The excess calls are rejected if all of the query places are occupied.
  • Each announcement is limited by a maximum listening time and number of repetitions.
  • the task of the intelligent network is to change the selected IN number depending on the service parameters defined in the
  • the first digits of the dialed telephone number are evaluated in the SSP and the IN service is recognized.
  • the SSP sends a request for further call handling to the SCP with the message PROVTDE INSTRUCTION.
  • the message contains the IN- selected by the service user as a parameter. 5 subscriber numbers (CALLED-PARTY-ADDRESS) and the call number of the call (CALLING-PARTY-ADDRESS).
  • Service logic program addressed for the corresponding IN service The subscriber-specific traffic management program addressed via CALLED-PARTY-ADDRESS is activated.
  • a destination for establishing the connection is determined, which can be a telephone number or an announcement.
  • the traffic management program may result in requirements for connection monitoring, such as monitoring "subscriber busy" and "subscriber not answering”.
  • the SCP saves the results in the connection-specific context and sends the CREATE-JOIN and MONITOR messages to the SSP.
  • the message contains as parameters CALLED-PARTY-ADDRESS and EVENTLISTE, which specifies the events to be monitored.
  • the SSP monitors the connection establishment to the B subscriber if this has been specified in the EVENT LIST. If the B-subscriber does not respond, the connection towards the B-subscriber is triggered after a timeout and the SCP is informed of the event with the EVENT message.
  • An alternative destination is determined from the traffic management program (rerouting) and a message CREATE-JOIN and MONITOR with corresponding parameters is sent to the SSP.
  • the SSP uses the telephone network to establish a connection to the B subscriber to the destination number transferred with CREATE-JOIN, or to an announcement. After the B participant reports, the connection is switched through.
  • EVENT (CALL-END) transferred.
  • the confirmation of this message by the SCP is monitored with a timer. If no confirmation has been received by the end of the timer, the EVENT (CALL-END) message is repeated. 8.
  • the SCP sends a message to end the TCAP dialog.
  • the connection-specific context is reactivated in the SCP.
  • the received timestamps are saved together with the data stored in the context (CallTickets). They will later be transferred to the SMS for further processing. Counters kept in the SCP (e.g. for successful calls) are counted up (counter tickets).
  • Points 4, 5 and 6 in this process only occur when rerouting.
  • overload protection mechanisms are provided within the IN.
  • Overload protection means that the SSP rejects IN calls without requesting the SCP according to certain specifications.
  • overload protection mechanisms are AUTOMATIC-CALL-GAPPING (ACG) or the LEAKY-BUCKET method. A service and / or target-dependent overload protection is possible.
  • a service control point is usually a multi-layer system with a hardware foundation and several, usually three layers of software.
  • the hardware foundation consists of a computer with one or more processors processing in parallel with connecting cables, hard drives, magnetic tapes, terminals and printers.
  • the first software layer contains the system software.
  • the second software layer (NODE software) contains general functions for the service application.
  • the third software layer consists of the application, which supports the call processing services.
  • a parallel processing architecture of the SCP it has a plurality of processors, each of which is an autonomous unit with CPU, main memory, power supply and input / output processor and which are connected to one another with a bus system.
  • the various SCP software layers do not contain any 7 processes belonging to the operating system, eg for communication between the processes or for effective management of the local cache, application processes that are required for processing an IN message.
  • An IN message arriving at the SCP thus runs through a sequence of processes in different layers of the SCP, which results in the generation of an IN message from the SCP to the SSP in response to its request for call handling.
  • the processes can be service and / or service subscriber dependent or can be used independently of all IN messages.
  • the processes are implemented in one or more incarnations on all or selected processors of an SCP.
  • the processing of an IN message in the SCP is usually carried out according to the following scheme, implemented by calling a predetermined chain of individual processes:
  • a message from the SSP is received and forwarded to the SCP computer.
  • the SCP computer receives the message, memory is made available by and the message is checked for its scope.
  • the context for call handling is created.
  • a routing tree is loaded from memory or from the hard disk.
  • the call number to be dialed is determined from the routing tree.
  • the context of the call is saved and a response to the SSP is created.
  • the reply is sent to the SSP as a new IN message.
  • connection end treatment after the connection from the exchange to the SSP has been triggered by the caller is processed analogously to the connection establishment treatment described above by a corresponding process chain.
  • An IN message in the STP / SRP is also processed by processing a predetermined chain of successive processes.
  • overload protection Another critical element in the operation of an intelligent network is overload protection, which is intended to stabilize the system as close as possible to its performance limit. The determination of appropriate overload protection parameters is difficult in practice, so that 9 There is a need to determine the optimal settings for overload protection depending on other network configurations regardless of network operation and to transfer them to the real network.
  • the invention is therefore based on the object of a tool for
  • the user should be able to specify and change the network configuration and the type of call handling within the network components within a wide range, so the simulation should be independent of the IN platform selected.
  • Statistical data on the performance of the network are to be generated, which allow a comparison of data measured with real IN components, but also those data are to be made available to which no access is possible in real networks, such as specific logging of calls Processing times when running through the intelligent network.
  • the problem is solved in a simulator for simulating the performance of an intelligent network (IN), which has the following components:
  • a module for the simulation of IN typical event sequences (traffic simulator) according to the rules of traffic theory; 2. a module for event-oriented simulation of the service control point (SCP simulator) using process models;
  • the modeling of the SCP forms the core of the simulator. Using queue models / process models, a detailed modeling of the software structure of the SCP can be realized. Another module that 10 Traffic simulator, is required in the IN simulator to generate IN-specific loads and to generate realistic input for the SCP simulator.
  • the core of the simulator is a computer program. When starting or during simulation, this program accesses files in which parameters for configuring the network or network components, for specifying communication services, i.e. Type and sequence of call handling, as well as other parameters relating to the simulation sequence, e.g. Information about the traffic volume is stored. These files can be written on and changed by the user in a known manner.
  • the simulation parameters are preferably entered using a computer screen and keyboard. The simulation parameters are saved and can be changed individually or in their entirety before a new simulation is run, so that the influence of individual parameters on the simulated IN performance must be analyzed.
  • the type of simulation used corresponds to the so-called event-controlled simulation.
  • IN-specific events are generated which run through the individual components of the simulator for processing.
  • the processing times in the individual simulation modules, possibly also in sub-components of the simulation modules, are also recorded.
  • the IN simulator preferably has a module for event-oriented simulation of signaling system No. 7.
  • This SS7 simulator works on the basis of queue models, as far as functionalities in the SS7 integrated processors are to be simulated, and / or only imparts a constant delay time to a message, which takes into account the finite running time in the signaling channels between SSP and SCP.
  • the components to be simulated within the SS7 simulator are the processors / process chains in the SSP level, the STP / SRP level and, depending on the network configuration of the SCP level, e.g. an SCP input processor (FRONT END SYSTEM), which is the interface of the SCP forms the signaling system.
  • FRONT END SYSTEM an SCP input processor
  • a module for simulating overload protection mechanisms modifies the number of events processed by at least one of the other simulation modules as a function of the load on one or more simulation modules, for example as a function of the queue length, and / or of user-definable parameters.
  • the user-definable parameters are, for example, load limits which, when exceeded, activate the overload protection. Instead of firmly defined limits, a "fuzzy" decision can also be provided, for example by means of fuzzy logic.
  • An overload protection simulator which receives its control parameters from the SCP simulator, accesses the traffic simulator and regulates the amount of IN events generated or passed on by the traffic simulator depending on the control parameters, is most appropriate to real conditions.
  • the overload protection simulator preferably emulates the automatic call gapping (ACG) mechanism. All calls / events going beyond a certain number are rejected within a certain time interval.
  • ACG automatic call gapping
  • the modules traffic simulator, SCP simulator and possibly SS7 simulator and overload protection simulator represent independent simulators of the corresponding network components. Internally, their functions are either linked via files (file mode) or preferably integrated via an organization program (online mode) that executes the processing of the individual IN events is guaranteed across all components of the IN simulator.
  • Simulation modules in the form of write or read access to files in which data relating to the configuration of the network or the 12 simulating network components and possibly the data generated by one of the simulation modules are stored.
  • a simulation run begins with the generation of traffic at the IN by the traffic simulator.
  • the generated messages PROVIDE INSTRUCTION with their generation time t1 are stored in EVENT or CALL END) in a first transfer file and read in by the simulation module to be subsequently called up. It continues to be everyone
  • this second simulation module is the SCP simulator. If the SS7 is taken into account, however, the first file is transferred to the SS7 simulator. In this case, the messages are written to a second transfer file after passing through the SS7 simulator, supplemented by the SS 7 exit time t2, which the SCP simulator accesses.
  • the SCP simulator generates a CREATE-JOIN or CALL END message for each entry in the file transferred to it and writes it to a third file with the exit time t3. Before the message arrives in SSP, the SS7 simulator may be run through again, with the SS7 exit time t4 being logged.
  • File operation is very well suited to investigate the behavior of individual network components separately from the network, i.e. without feedback.
  • the behavior of the individual components can be quickly and directly, for example, by modifying the corresponding simulation parameters 13 determine.
  • Individual IN components can be modified and analyzed separately.
  • the file mode also makes it easy to track individual EVENTS between the components.
  • the stationary behavior of the overall system can only be determined iteratively with suitable initial conditions in file mode.
  • an organizational program ensures that the partial simulations run quasi-parallel.
  • the simulator is thus able to simulate the network as a whole and, in particular, also takes feedback into account directly between the components.
  • the implementation of the parallel processing of messages in the network components into a sequential or quasi-parallel processing of the IN events in the simulation modules is implemented with the help of event calendars.
  • An event calendar is a list of all events to be processed by an element, e.g. the simulator, a simulation module or a sub-component of a module, e.g. IN messages or individual processes that are entered in this list in chronological order.
  • the online simulator determines which event is to be processed next (event-oriented simulation).
  • the starting time of the next event is additive from the starting time and the duration of the previous event.
  • the global event calendar which contains the events to be processed by the entirety of the simulation modules in chronological order, plays a central role in realizing the quasi-parallel operation of the simulation modules.
  • the simulator uses the global event calendar to determine which partial simulation is to be called up at which simulation time.
  • Internal events are references to the local calendar of the corresponding simulation modules. They relate to advancing a simulation module by a single simulation step.
  • External events represent the input of an IN message in a partial simulation, they stand for messages between the 14 simulation components are sent and serve the communication of the ul ulation components with each other.
  • Call-independent events In a further development of the invention, those events are also entered in the global calendar that are independent of IN events and e.g. belong to the simulation of the operating systems in the sub-components.
  • All events generally cause the respective simulation module to generate a subsequent event, which in turn is entered in the global and possibly also in the local event calendar. Some events cause logging after processing, which can be used to track how quickly a message was processed by the respective simulation module.
  • the functionality of the IN simulator is preferably accessible to the user via a user interface.
  • This interface takes over the management of one or more simulations by providing input masks for entering the simulation parameters of the individual simulation modules, storing the entered data in corresponding files and storing them in relation to the simulation.
  • the generation of a new simulation is made possible by the user copying and modifying selected parameters.
  • the user interface includes a largely independent file management of the system of configuration and result files belonging to each simulation.
  • the user has the option of having all the simulated data displayed.
  • the "measurands" selected by the user e.g. Utilization of the SCP, queue length in the SCP, traffic volume in the IN, are prepared with the help of a graphics program and can be displayed as graphics on the screen of a computer.
  • the simulation results of both a simulation and different simulations can preferably be displayed together on a screen.
  • the creation of output files for further processing in other programs is preferably possible via file filters.
  • Figure 1 The topology of an intelligent network 15 Figures 2 and 3 The structure of a simulator according to the invention, operated in file mode
  • Figure 4 The structure of a simulator according to the invention, which can be operated in file and online mode
  • FIG. 14 A schematic, object-oriented model of an SCP
  • FIG. 15 arrangement of the SS7 layers F Fiigguurr 1166 modeling of the MTP3 level of the SRP
  • FIG. 19 shows the implementation of the overload protection simulator in the IN simulator in online mode.
  • FIG. 20 shows the implementation of the overload protection simulator in the IN simulator in file mode.
  • FIGS. 21, 22, 23 examples of examples determined with the IN simulator
  • FIG. 1 shows the topology of an intelligent network to represent the simulation concept.
  • An intelligent network essentially has three logical components, the Service Control Point (SCP) 109, the Service Switching Point (SSP) 102 and the Signal Transfer Point or Signal Relay Point (STP or SRP) 103.
  • SCP Service Control Point
  • SSP Service Switching Point
  • STP or SRP Signal Transfer Point or Signal Relay Point
  • the SSP level accepts signing requests from customer devices considered external 16 one of the exchanges 101 of the telephone network and operates the connection establishment for such IN-specific connections.
  • the SCP level contains procedures and databases for call evaluation and connection management. This information is used to find the way to connect through the telephone network.
  • the SCP or SRP takes on switching functions between SCPs and SSPs. Communication between the components SSP, SCP and STP / SRP follows via signaling system No. 7 (SS 7). For this purpose, there are usually a large number of signaling channels 106, 107, 108 between STP / SRP and SSP or STP.
  • the three logical components SSP, SCP and STP / SRP can be integrated in one physical device, e.g. in an exchange.
  • a call with an IN-specific call number is initially transferred to an SSP, which, after receiving the further processing information from SCP, transfers the connection to the respective destination.
  • the SSP thus represents the interface between the telephone network and the intelligent network.
  • SSP functionalities can also be integrated directly into a switching center.
  • the IN traffic coming from the SSPs into the intelligent network is simulated with the traffic simulator, the function of the SCP is modeled with the SCP simulator, the SS7 simulator models the functions of the SSPs, the STPs / SRPs , the SCP input processors 104 and the connecting lines between these components.
  • the user of the simulator has the option of freely selecting the network topology within the framework of the entries for the network configuration and thus adapting the structure of the simulated network to correct specifications.
  • User-definable simulation parameters include the number of SSPs 102, the number of STPs / SRPs 103, and the number of SCP input processors 17 104 the number of character channels between an STP / SRP and an SCP or an SSP, and possibly also the number of SCPs.
  • FIG. 2 shows the structure of an IN simulator according to the invention, operated in file mode, the simulation modules traffic simulator 201 and SCP simulator 202.
  • the traffic simulator 201 generates according to the user information, which are in input files 208, 209, 210, 211, 212 are stored, taking into account the data possibly stored in the transfer file 204, an IN-specific traffic volume, ie a sequence of events that represent IN messages from one or more SSPs to the SCP.
  • the input files 208 to 212 are preferably accessible to the user via a common user interface and are read in by the traffic simulator 201 at the start of the simulation.
  • the input files 208 to 212 contain parameters which each relate to different aspects of the simulation, e.g.
  • Redirection probability 1 information on the average number of calls per time unit and service for one or more consecutive time intervals. It goes without saying that the number of input files 208 to 212 is arbitrary and, for example, all user information, including those relating to other simulation modules, can be stored in a fixed number of files, including a single one.
  • the SCP simulator 202 has an SCP input file 207, in which user information relating to the SCP configuration is stored and which the SCP simulator 202 reads in at the start of the simulation.
  • the traffic simulator 201 and SCP simulator 202 modules are operated in succession.
  • the sequence of events generated by the traffic simulator is written into a first transfer file 203 which contains the sequence of events now to be processed by the SCP simulator 202.
  • the SCP simulator reads in this transfer file 203 and processes the events stored therein.
  • the processed ones 18 events are entered by the SCP simulator 202 in a second transfer file 204. This is passed on again to the traffic simulator 201 while the simulation is running, but like the first transfer file 203 can also be fed directly to the evaluation.
  • the transfer files represent the event calendars of the respective receiving module.
  • the data generated by the traffic simulator 201 or by the SCP simulator 202 are stored as a data record, each of which has at least one time stamp that indicates the generation time of the corresponding message indicates on the traffic simulator or on the SCP simulator, and contains an identification number which allows the assignment of two or more messages as belonging to a call.
  • the difference between the two time stamps indicates the processing time of a message in the SCP.
  • the simulator outlined in FIG. 2 can thus directly simulate the reaction of the SCP to a given traffic volume. Signaling system No. 7 is not taken into account.
  • the simulation modules 201, 202 also store statistical data, e.g. with regard to the processor load in the SCP, the queue length in the SCP or the line load from and to the SSP, in output files 205, 206. The data recorded there are also available for further evaluation of the simulation results.
  • FIG. 3 shows the structure of a simulator according to the invention operated in file mode with the simulation modules traffic simulator 301, SS7 simulator 303 and SCP simulator 302.
  • the simulator shown in FIG. 3 is only around the module SS 7- Simulator 303 extended. The result of this is that four transfer files 304, 305, 306, 307 are now transferred between the modules during the sequential processing of the partial simulations.
  • the simulation of the intelligent network begins with the generation of an IN-specific traffic volume.
  • the traffic simulator 301 receives the input files 312 to 316, which correspond to the files 208 to 212 from FIG. 2, if present, the transfer file 307 is also read.
  • the sequence of events generated by the traffic simulator 301 is stored in the first transfer file 304.
  • the SS7 simulator 303 first has the SS7 input file 317 in which, for example, data relating to the configuration of the SS7 system are stored.
  • the SS7 simulator 303 stores the event sequences it has processed in a second transfer file 305 which is read in by the SCP simulator 302 when it is called.
  • the sequences of events processed by the SCP simulator 302 are then entered in a transfer file 306.
  • the SS7 simulator 303 is reactivated and processes the sequence of events stored in the third transfer file 306, the results being stored in the fourth transfer file 307.
  • the traffic simulator 301 is now activated again and the cycle SS7 simulator, SCP simulator, SS7 simulator is run through again in order to simulate feedback between the network components. The iteration is carried out until the changes in the traffic data in one or more of the transfer files 304 to 307 (or above 203, 204) have fallen below an acceptable level for the user and the system has thus reached a steady state.
  • Statistics data relating to the individual simulation modules 301, 302, 303 are written in output files 309, 308 and 310, respectively.
  • these are, for example, the utilization of the SRP processors or the number of occupied connections from the SRP to the SCP or to the SSPs.
  • the data stored in the transfer files are call-specific data records, each of which contains at least one time stamp. This timestamp results from the current simulation time when generating or processing the associated message in the corresponding simulation modules. The processing times in the respective simulated network components can thus be calculated by forming the difference.
  • FIG. 4 shows the structure of a simulator according to the invention which can be operated in the file and online modes.
  • the simulator has the simulation modules traffic simulator 401, SS7 simulator 403 and SCP simulator 402 already shown and described in FIG. 3. As shown above, these communicate via transfer files 406, 407, 408, 409. 20th
  • the simulator shown here additionally contains a module for simulating the overload protection 404. This regulates the event sequences generated or passed on by the traffic simulator 401 depending on certain user-defined parameters, stored in file 424, and on the load on the others Simulation modules.
  • the simulation modules 401, 402, 403, 404 are linked by a common organizational program, the online simulator 405.
  • Output files of the online simulator 405) via which the modules can be configured and system data determined can be read out.
  • the dashed arrows in Figure 4 symbolize file operations, as in Figures 2 and 3, while the solid arrows describe direct communication, e.g. by linking through a common organizational program.
  • An arrow begins with the component that passes parameters or messages to another simulation part.
  • the simulator shown in Figure 4 allows both file operation with sequential calling of the individual simulation modules as well as
  • the user interface is available with the traffic SS7 and. SCP simulator in connection; the respective simulation is transferred from the user interface with the corresponding
  • the bidirectional connection between user interface 410 and online simulator 405 allows on the one hand the simulation to start with the corresponding parameter transfer and on the other hand the return of "measurement data" for graphical output during runtime (online mode). Furthermore it is 21 allows the user to temporarily interrupt the simulation process or to end it prematurely.
  • the simulation modules 401, 402, 403 and 404 are programmed in the online simulator 405, which controls the quasi-parallel sequence of the partial simulations by sending and receiving messages, which are managed in the global event calendar.
  • the online simulator 405 controls the quasi-parallel sequence of the partial simulations by sending and receiving messages, which are managed in the global event calendar.
  • all communication processes between the modules traffic simulator 401, SS7 simulator 403 and SCP simulator 402 thus take place via the online simulator 405.
  • the transfer files 406 to 409 are in the
  • the online simulator 405 causes the entry of predeterminable protocol sizes, e.g. the time stamps tl to t4 described above, the SCP load, data on the network load or the number of lines used, in log files 417, 418, 419, 420.
  • the data stored there can be output and visualized in a known manner on the user interface.
  • overload protection mechanisms can only be sensibly implemented in online mode.
  • the overload protection module 404 therefore has no direct connection to the SCP simulator 402, on the basis of which the overload protection simulator 404 regulates the number of events generated by the traffic simulator 401.
  • a connection between the SCP simulator 402 and the overload protection simulator 404 only exists in online mode indirectly via the online simulator 405.
  • FIG. 5 shows the basic sequence of an IN simulation from the point of view of the user.
  • the simulation modules themselves are not shown, but are processed within the black box 501.
  • the overload protection simulator 502 and or the SS7 simulator 503 can be switched on or off, symbolized by switches in FIG. 5.
  • the user can choose between file and online mode, also symbolized by a switch. 22
  • the user has the option of defining the actual simulation parameters, i.e. the network configuration to be simulated, the traffic volume, etc.
  • the simulation modules i.e. the network configuration to be simulated, the traffic volume, etc.
  • the simulator 501 determines the predetermined output data based on the previously determined or called simulation parameters, e.g. Traffic, CPU usage, queue length as a function of simulation time, and writes them to files.
  • the data can now be displayed on the screen or, stored on data media, can be used for further processing.
  • FIG. 6 shows an example of configuration parameters of the traffic simulator as well as numerical values for these.
  • the parameters shown in the table in FIG. 6 can be broken down into service-specific parameters that can be set separately for all services to be simulated, televotum parameters that relate to the service
  • the service-specific parameters can be set for the following IN services: Freephone (FPH), Tele-Info-Service (TIS), UniverseUe phone number (UNU), the in-service FPHL and Televotum (TVS). Not all of the parameters that can be set for the other services are useful for the Televotum service; these are therefore marked with an X in the corresponding column.
  • normal telephone traffic NVK
  • NVK normal telephone traffic
  • the service-specific parameters are the average call duration, average announcement duration, maximum announcement duration, the number of announcement locations, such as announcement and diversion probability, as well as for the probability of 23 Redirection by "subscriber busy”. These parameters are required to determine the probability of generating a follow-up event at every simulation time, i.e. the probability of generating an event EVENT or EVENT (CALL END).
  • the Televotum parameters can be specified separately for each Televotum service subscriber TV1, TV2 etc. In the example shown here, only two service subscribers are active.
  • the parameters that can be set are: target value SSPl or SSP2, number of target values up to connection, start time, end time and end time for subsequent calls.
  • the "Target value” parameter specifies the number of televotum calls that must be received by the specified SSP so that a message to the SCP is generated. If this parameter is set to 1, the option is Televotum without counting, if the value is greater than 1, it is Televotum with counting in the SSP.
  • the following parameter "Number of target values to connection" specifies whether and how many calls a connection to the service subscriber is established.
  • the Televotum service Since the Televotum service is usually offered within tight time limits, the start and end times of the service are provided.
  • the "End time for follow-up calls" parameter specifies the point in time at which incoming TV calls are directed to an informative, possibly service subscriber-specific announcement.
  • the Televotum parameters indicate the conditions under which a TV call initially generated by the traffic generator triggers an IN first event.
  • the following general configuration parameters can also be set:
  • the "Time to timeout” parameter specifies the time after which an SSP rejects a call after sending an IN message to the SCP and without receiving a response from the SCP.
  • the "Time delay for redirection” parameter specifies the delay in a call rerouting.
  • the number of lines for the Freephone service can also be specified.
  • the parameter "average waiting time of the A subscriber" specifies the average time interval after which the calling party 24 participants hang up if no connection has been established by then.
  • the following two parameters indicate the probability of a follow-up call following an unsuccessful connection and the maximum number of follow-up calls that can be generated.
  • each step or time interval preferably having the same time length.
  • the number of intervals and the interval lengths can be specified.
  • the probability that a call with a special service or service subscriber identification arrives at an SSP is determined for each simulation time or for each simulation time interval.
  • the length of the simulation time intervals is preferably substantially below the length of the IntervaUe for which an average traffic volume has been specified by the user.
  • the length of the simulation intervals is preferably in the nanosecond range, while the traffic volume changes on the time scale of seconds, for example 10-100 s.
  • the length of the simulation time interval is preferably too long Select 25 that a maximum of one call is generated per interval and that all calls generated can be listed in chronological order.
  • the respective current probability is calculated assuming a given probability increase and the predetermined current average traffic volume for the service treated, service subscriber or SSP.
  • the probability distribution used is preferably a Poisson distribution, since this describes the statistical arrival of mutually independent events and thus best reflects the statistical fluctuations in telephone traffic.
  • a timely sequence of events is thus generated for each service, service subscriber and / or SSP, the number of calls per unit of time statistically fluctuating around the previously specified instantaneous average.
  • each generated call becomes a IN-specific event that contributes to the utilization of the intelligent network and is therefore relevant to simulating the performance of the IN, in particular the SCP.
  • the traffic generator generates follow-up events associated with an IN call or first event, taking into account the probabilities entered in the configuration file, which relate to the further fate of an IN event. If, for example, the IN connection to a real subscriber or the switching to an announcement location is properly established by the SCP in the simulation based on the connection handling information (CREATE-JOIN), the call is ended after the specified average call or announcement duration by the 26
  • Traffic generator generates the follow-up event EVENT (CALL END) and enters it in the transfer file or in the global event calendar. If the IN connection does not come about in the simulation with the real participant who is also involved in the SCP, which is determined by the traffic generator taking into account the probabilities specified for this, the traffic generator generates the IN message EVENT as a subsequent event, with which, for example, rerouting -Information is requested from the SCP. In this way, the traffic generator is able to generate IN-typical event sequences that largely correspond to real traffic volumes in the IN.
  • the following parameters are stored for each IN event: the identification number of the call, the time t1 at which the message is sent by the SSP, the identification number of the message, e.g. 1 for PROVTDE INSTRUCTION, 2 for EVENT, 3 for EVENT (CALL
  • a code number for the global title is also generated as a routing criterion and stored as a parameter of the IN event.
  • the GT class is also generated using a predefined probability distribution.
  • the STP / SRP simulator then preferably initiates GT-specific process chains which simulate the routing functions at the STP / SRP level, that is to say, for example, the transfer of the call to the network of another network provider.
  • the assignment of the events generated by the traffic simulator to useful and load classes is also advantageous. Call-related IN events are assigned to a user class, while management traffic between the IN levels can be simulated by events of a load class, for example. For each event generated by the traffic simulator, a corresponding class code is generated and saved, which is recognized by the other simulation modules and, if necessary, also determines the further processing of the event. 27 In online mode, the subsequent events are generated by the traffic generator during simulation operation with the given probabilities, after the associated first event has run through the simulation modules SCP simulator and, if applicable, SS7 simulator, i.e.
  • the IN-specific first events are generated during the course of the overall simulation, i.e. for everyone
  • Time of simulation e.g. at ns intervals.
  • an intervention by the overload protection against a current overload of the other simulation modules can be simulated and a call rejected before the generation or forwarding of a corresponding IN event.
  • a sequence of the calls arriving at the SSP or the SSPs which as a rule result in an IN event, can be generated before the start of the simulation according to the traffic theory methods defied above and processed during the simulation, i.e. passed on as an IN event or dropped due to overload protection.
  • the utilization of the drawing channels in the intelligent network can be used for each simulation time 28 can be determined. Based on the user-defined probabilities of the further fate of the call (e.g. conversation or announcement of a certain medium duration), the number of busy voice connections to and from the SSPs and / or the number of busy customer lines for subscribers to the Freephone service can also be logged and output as a function of time become. Furthermore, as a function of the simulation time, it is possible to output how many calls were rejected in different stages, for example immediately after generation due to overload, after the timeout in the event of the SCP not responding or because all announcement locations have been occupied.
  • the simulation time it is possible to output how many calls were rejected in different stages, for example immediately after generation due to overload, after the timeout in the event of the SCP not responding or because all announcement locations have been occupied.
  • Figure 7 shows the principle simulation in file mode. After starting the simulator, the input files of the individual simulation modules are read.
  • the traffic simulator determines whether a file with messages from the SCP already exists (transfer file 204 from FIG. 2 or 307 from FIG. 3). If yes, this data is analyzed with regard to the SCP response times and taken into account in the generation of the event sequences by the traffic simulator. If not, the next step is taken without analysis and a default value is used for the SCP response times.
  • the initialization of the counters includes setting an internal simulation clock to zero and initializing the status variables and statistical counters with initial values.
  • a start event is generated, i.e. a first PROVTDE INSTRUCTION message, and entered in the event calendar.
  • the event calendar also contains events to be processed during the simulation, sorted according to their start time.
  • the actual simulation begins within a loop.
  • the abort condition is then queried, the simulation being aborted when the current simulation time t is greater than a predetermined simulation duration.
  • the next event is first carried out from the calendar within the loop and the simulation clock is switched to the time of the following event. When the simulation starts, this next event is the first event generated after the simulation.
  • the event type of the event to be processed is determined and the associated event routine is then processed. 29
  • the first event entered in the calendar is usually a new call (NEWCALL).
  • the associated event routine causes the traffic generator to generate the next call and to simulate the connection setup to the SSP.
  • the NEWCALL event routine simulates the sending of an IN message
  • PROVTDE INSTRUCTION from the SSP to the SCP by generating a corresponding event and entering it in the event calendar or in the transfer file.
  • the SCP then sends the CREATE-JOIN message to the SSP;
  • the receipt of the CREATE-JOIN from the SCP is entered in the event calendar as an event at the time of the current simulation time plus the SCP response time.
  • the simulation clock is pre-set at the next event, this event is read from the calendar and processed if the simulation time has not already expired. The time between two events is skipped.
  • next event is the receipt of the CREATE-JOIN message from the SCP.
  • the continuation of the connection establishment by the SSP is simulated with the event routine (CONNECTSSPCON).
  • CONNECTSSPCON the event routine
  • the probabilities discussed above are used to determine whether a connection to the B subscriber is successful (follow-up event CONNECTB), where the B subscriber can be a real subscriber or an announcement, or whether a call for previously unsuccessful attempts
  • the loop calling an event from the event calendar, going through the corresponding event routine, possibly generating a subsequent event and entering it in the event calendar, setting the simulation time to the time of the next event entered in the event calendar, and calling it up will continue until the previous one set simulation time is reached, or until an event occurs that marks the end of the simulation.
  • the data entered in the event calendar or in protoco files, generated and processed by the simulator is available for evaluating the performance of the intelligent network or individual components.
  • Figure 8 shows the basic simulation sequence in online mode. First, the configuration is determined by the user, with the corresponding
  • Configuration files can be read from the simulation modules.
  • the traffic, SS7, SCP and overload protection (ACG simulator) are active and are managed by the common organizational program, the online simulator.
  • ACG simulator overload protection
  • a start event is first generated by the traffic simulator.
  • the events entered in the global event calendar are called up in a loop in chronological order, the associated event routines are processed, and any subsequent events generated are entered in the global calendar.
  • Each time an event routine ends, the simulation time is set to the time of the next event and processed.
  • a predetermined maximum simulation time which is compared with the current simulation time each time the loop is run, is again used as the termination condition for the loop.
  • the sub-simulations are ended by releasing the dynamic memory. If the end of the simulation is not reached, the 31 Community memory, which the user interface accesses during the simulation, is updated so that the current system data can be displayed to the user immediately. The system data for the overload protection simulation are also updated. Finally, the measured data determined, that is to say SCP utilization, queue length, etc., are logged at constant time intervals and entered in the corresponding log files and / or visualized for the user. Then the next event in the calendar is processed.
  • the internal events are routines that affect the state of only a single simulation module.
  • Each simulation module is an independent event-oriented program with a large number of events and its own local calendar for managing them. From the point of view of the sequential control of the overall simulator, there are three global internal events TRAFIC INTERN, SS7 INTERN and SCP INTERN in this example, each of which represents references to the local event calendar.
  • Figure 9 shows schematically the processing of such an internal event from the point of view of the online simulation.
  • the next internal and possibly the next external event is generated depending on the internal program sequence and entered in the local calendar of the simulation module.
  • all required parameters of the event are transferred to the sequential control system in order to be sorted into the global calendar of the overall simulation.
  • the other events of the simulation process shown in FIG. 8 are external events which serve for communication between the simulation modules. They correspond to those sent from one component to another in a real intelligent network
  • Messages e.g. PROVIDE INSTRUCTION, CREATE-JOIN, EVENT.
  • the external events occurring here are: PROINST TO SS7, EVENT TO SS7 and SSP CALLEND TO SS7, which are the PROVIDE messages 32 INSTRUCTION, EVENT or EVENT (CALL END) of the SSP correspond to the SCP.
  • the internal events mentioned are generated by the traffic simulator (routine: TRAFFIC INTERN) and find their correspondence in the file mode in the events which are entered in the first transfer file 304 (FIG. 3).
  • the external events PROVTNST TO SCP, EVENT TO SCP and CALL END TO SCP stand for the messages PROVIDE INSTRUCTION, EVENT or EVENT (CALL END), which are transferred from the SS7 system or from the SRP / STP to the SCP. These events thus correspond to the events entered in the second transfer file 305 (FIG. 3).
  • the SCP's response is to SCP CALL END TO SS7 and CREATE-JOIN TO SS7.
  • the first event confirms the connection initiation, the second simulates the transmission of
  • Connection establishment information correspond to the events entered in the third transfer file 306. They are generated by the SCP simulator and are aimed at the SS7 simulator.
  • the external events CALL END TO SSP and CREATE-JOIN TO SSP are generated by the SS7 simulator and are used to forward a message from the SCP to an SSP through the SS7 system.
  • the corresponding events are stored in the fourth transfer file 307 in file mode.
  • the message CALL END TO SSP is only required in the case of an inactive SS7.
  • An external event within the sequential control system is processed by entering the corresponding message in one of the simulation components. It is possible that the component is caused by the message to generate a new internal event, which is then passed on to the online simulation and entered in the global calendar. After an event routine has been processed, the next event is carried out from the global calendar and the simulation clock is updated, ie set to the start time of this subsequent event. 33
  • the traffic simulator is called up and generates a new call. Based on the current load on the other simulation modules, it is decided whether this new call is rejected by the overload protection (ACG). If the call was rejected by the overload protection, this fact is logged and the event routine is ended. If the new call was not rejected, it is included in the simulation, ie the corresponding PROVINST TO SS7 event is entered in the global event calendar. A new element is inserted in a log file for the generated call, the following data being saved: The
  • Identification number of the respective call which is generated by the traffic simulator when it is generated, the service identification numbers of the call, the number of the SSP to which the call arrives, the message identification number, i.e. whether the message PROVTDE INSTRUCTION or EVENT is present, and the time t1 at which the corresponding message PROVIDE INSTRUCTION or EVENT was generated for the current call.
  • this log view is supplemented by further time stamps, namely after the routine PROVINST TO SCP or EVENT TO SCP has been processed by the SS7 simulator (time stamp t2), after the routine CREATE-JOIN SS7 has been processed by the SCP simulator (time stamp t3) and after the routine CREATE-JOIN TO SSP has been processed by the SS7 simulator (time stamp t4).
  • the second and third time components only contain valid values if the SS7 simulator was active during the simulation.
  • t2-tl delay of a message in SS 7 on the way to the SCP
  • t3 - 12 delay of a message in the SCP
  • t4 - 13 delay of a message in SS7 on the way to the SCP
  • t4 - tl total delay of a message in the IN.
  • the network load is saved in constant time intervals during the simulation process. No call-specific information is saved, but rather global statistical network data.
  • the following variables are preferably logged: the time of the current measurement, the number of calls to the IN per second, the number of messages currently being processed in SS7 on the way to the SCP, the number of messages in the SCP as well as the number of messages in SS 7 on the way to the SSP.
  • the utilization, the queue length and the number of processed messages (dispatches) are determined for each processor and saved in a log file.
  • the online simulator accesses this data and writes the values determined via external CPUs to a file.
  • the data can be displayed through the user interface during online simulation.
  • the number of lines used to and from the SSPs is determined on the basis of the traffic data and logged as a function of the simulation time.
  • Figure 8.a shows the relationship between the events used to supplement Figure 8.
  • the simulator from FIG. 8 was supplemented by a separate module for simulating the SRP, which can also be part of the SS7 simulator, which is why events of the type SRP_INTERN also occur here.
  • the four internal events TRAFFIC NTERN, SS7JNTERN, SRP NTERN and SCP_INTERN cause a simulation module to be called up to process an event. Other external events serve to transition from one simulation module to the next.
  • the start event in the overall simulation is always a TRAFFIC_INTERN event, since the traffic simulator is the queue of the IN calls. 35
  • each simulation module can generate a follow-up event for processing by the same simulation module.
  • one of the external events identified by an outgoing arrow can be generated.
  • the online simulator receives this information from the respective simulation module.
  • the call of an external event corresponds to the sending of a message to the respective other node of the IN.
  • macn distinguishes three messages. These can be found in three different transitions from the traffic generator to the SCP simulator.
  • a TRAFFIC_INTERN event is called, which generates this message and assigns a unique number (CaUID) for this call within the simulation. This is followed by a PROINST-TO-SS7, EVENT-TO-SS7 or SSP-CALLEND-TO-SS7 event and another TRAFFIC_INTERN event, according to the message, so even more traffic may be generated.
  • the external event is then processed and results in an SS7 INTERN event.
  • the SCP simulator After processing an SCP-INTERN event several times, the SCP simulator requests the online simulator to send a message to the SSP simulator.
  • CREATE-JOIN From there only events of the type CREATE-JOIN lead to a TRAFFIC-INTERN event; Events of the type CALLEND do not cause the traffic generator to generate associated follow-up events.
  • Figure 10 shows schematically the principle of SCP simulation. Again, it is an event-controlled simulation, whereby only discrete event times are considered and state changes can occur at each event time.
  • the SCP simulator has a local event calendar in which all events to be processed by the SCP simulator are entered in chronological order.
  • Messages represent requests from the SSP or SS7 to the SCP for call handling, the arrival of a message in the SCP or in the SCP simulator starting a service processing program consisting of a predeterminable process sequence.
  • a message corresponds to a global external event.
  • (Local) internal event A local internal event leads to the termination of a process or event and generation of a new process or corresponding event, the type and properties of which result from the process chain defined in the service processing program.
  • (Local) external event A local external event is generated when a service processing program has ended, i.e. after .working of the last process specified in the process chain. An external event leads to the sending of a message to the SSP or SS7 and thus to the generation of a global external event and its entry in the global event calendar. 37
  • Figure 11 shows an example of configuration parameters of the SCP simulator.
  • the upper part of the TabeUe contains a list of all processes to be simulated, which can be carried out by the SCP and which are involved in establishing or clearing the connection.
  • the individual processes are identified by a process identification number (process ID);
  • process ID process identification number
  • the specification of the process name only serves to simplify the adaptation of the configuration to the function of a real SCP.
  • Each process is assigned a process duration, which is specified here in milliseconds, and a priority.
  • the information is user-definable, so that, for example, the
  • a process sequence is assigned to each service, identified here by the service identification number, and service-specifically to each message PROVIDE INSTRUCTION, EVENT or EVENT (CALL END), identified by the message identification number.
  • the process sequence or the service processing program is defined by successive statements of the process IDs of the processes suspended above.
  • each message is assigned service-specifically to a CPU on which the process sequence is processed. All messages can also be processed on all available CPUs.
  • the delay of the ST2000 front end system which in some network topologies provides the interface between the SCP and the SS7 system, and the maximum counter reading for the Televotum service can be specified as parameters.
  • FIG. 12 shows a ModeU of the process management of a CPU 1201 on the basis of the SCP simulation within an SCP.
  • every mode of such process management can be adopted in the SCP simulator by defining the queues or event calendar accordingly.
  • the process management only determines the number and type of linking of the SCP queues or the local event calendar within the SCP simulator and thus how a message or the resulting individual processes are processed within the simulator.
  • the simulator can be adapted to user specifications within wide limits, so that remedial realities can be simulated. No specific hardware and / or software structure is specified, but remedial configurations can be modeled.
  • the CPU 1201 is connected to the SS7 by means of two local area networks (LAN) 1202, 1203, for example using two token bus LANs via the front end system ST2000.
  • LAN local area networks
  • a process receives the desired message, it joins the queue of the activated processes.
  • the activated processes are arranged according to priorities, while the events entered in the service-specific queues 1204 to 1207 are arranged chronologically.
  • the process with the highest priority within the priority queue 1210 receives the CPU and is processed there. For example, if a process cannot be processed by the CPU because incarnations of the process to be called are occupied, this non-executable process is managed in an additional queue 1209 until a process incarnation is available again and the process changes to the executable state; then it is enlisted in priority queue 1210.
  • FIG. 13 shows a further mode of process management of a CPU for simulating the SCP functions.
  • Messages arriving at a CPU 1301 are converted into a process sequence according to the service processing program.
  • the first of these processes is entered into a process-specific queue 1302, 1303, 1304, 1305 in order to be processed by the assigned process routine 1307, 1308, 1309, 1310.
  • the incoming processes are arranged in chronological order in the process-specific queues 1302 to 1305.
  • Each process routine 1307, 1308, 1309, 1310 is also assigned a specific priority P1 to Pn. Configurations are also conceivable in which the queues 1302, 1303, 1304, 1305 are only priority specific, i.e. Also, different processes have a certain priority, which are then processed in chronological order.
  • the process routines can exist in several incarnations for the same process, for example one copy per service.
  • the process-specific queues 1302 to 1305 are also service-specific. If a process routine 1307 to 1310 is ready, the next process is called from the corresponding queue 1302 to 1305; the process is then ready. If the CPU 1301 is also free, the process is processed. After a process has been processed, the CPU 1301 generates the process that follows the processed process in the process chain and enters it in the corresponding queue. Non-executable processes are maintained in an additional queue 1306 until they return to the executable state. Interrupted but executable processes are placed at the beginning of their queue and will be processed next if their priority allows.
  • FIG. 14 shows a schematic, object-oriented mode of an SCP simulator.
  • the simulator has a plurality of subunits, each of which simulates the function of a CPU 1401, 1402, 1403, 1404. These subunits can be assembled modularly to form the SCP simulator.
  • An incoming message is received by the front end system ST2000, reference number 1405, and, depending on the predetermined CPU selection criteria, passed on to a CPU 1401 to 1404 for complete processing.
  • the front end system 1405 is simulated with a constant delay time. It can also have its own queue within the SCP simulator.
  • a follow-up event e.g. the EVENT or EVENT (CALL END) message is automatically processed on the CPU on which the first event was already handled, since in reality the context for the call is only stored there.
  • the allocation of a first event (PROVIDE INSTRUCTION) to a CPU can be done according to various criteria:
  • statistical data of the SCP simulator can be used, e.g. the utilization of the respective CPU, the number of messages for processing in the CPU together with the current status of the CPU (active or inactive), the sum of the remaining waiting times other than processes running or waiting on the CPU.
  • this requires computing time during the ongoing simulation to determine the statistical data and the corresponding decision-making.
  • the independent recording of messages by the CPUs is provided: all first events (corresponding to the messages PROVIDE INSTRUCTION) are written into a queue common to the CPUs; the subsequent events (corresponding to the EVENT or EVENT (CALL END) messages) are entered in CPU-specific, possibly also CPU and message-specific queues. If the processor of a CPU is free, the next message can be read automatically from a CPU-specific or from the common queue.
  • each process of the process sequence can also break up into a plurality of dew processes, whereby other processes can take place between the dew processes.
  • At least one process routine 1408, 1409, 1413 exists on the CPU for each process 41 .s 1416, with which the processes entered in the process queue 1410, 1411 are processed when it is their turn.
  • a process routine can also be present in several incarnations on the CPU, for example the assignment of an event to one of the process routines is service-specific. This is symbolized in FIG. 14 by two blocks of process routines 1408, 1409, 1413 or 1414 to 1416, each with a process queue 1410 or 1411.
  • An incoming event is processed as follows: The event is first entered in the process queue 1410 or 1411 and waits for the corresponding process routine of the process to be called to become free. When the process is ready, the event is placed in the priority queue.
  • the events entered in the priority queue 1407 are processed in sequence by the CPU 1401. Wait events can occur during the execution of a process by the CPU, e.g. Simulate access to the hard disk. These wait events are generated randomly or also due to the process and entered in a queue 1412. These events have higher priority and interrupt a process running on the CPU 1401.
  • service-dependent counter events generated by a counter 1406 can be requested. Inquiries from external CPUs can arrive in this counter 1406 and block each other. This leads to an extension of the process processing times, although this does not burden the calling CPU.
  • the CPU utilization is determined by the SCP simulator to obtain SCP statistical data as follows: At every point in time specified by the user, e.g. Except for simulation seconds, the percentage of time within the previous, user-defined time interval ⁇ t that the CPU was active is calculated, i.e. All times of the individual processes run within the last time interval ⁇ t are added and their percentage of the time interval ⁇ t calculated.
  • the queue length as a further criterion for the SCP load results directly from the length of the respective queues or local event calendar.
  • FIG. 15 shows the arrangement of the SS7 layers which are involved in the dialog between the SSP and SCP and are therefore simulated with the SS7 simulator.
  • the top layer 1501 represents the layer of the SS7 users, that is to say represents the connection of the SSP or SCP to the SS7. From here, messages are sent or received in the intelligent network or the SS 7. Among them are the TCAP layer 1502, the SCCP layer 1503 and the MTP layers 1504 (levels 3 to 1) in the following order, each of which realizes certain SS7 functions with its own processors. The message flow from the SSP to the SCP takes place in the right
  • the SS7 levels 1502 to 1504 i.e. TCAP, SCCP, MTP 1-3, are modeled separately.
  • the individual processes on one level are replicated by delay times.
  • a queue mode U is used.
  • MTP3 level 1008 of the SRP within the SS7 simulator is shown in FIG.
  • the three processes occurring at this level are MESSAGE DISTRIBUTION (HMDT), MESSAGE DISCRIMINATION (HMDC) and MESSAGE ROUTING (HMRT).
  • HMDT MESSAGE DISTRIBUTION
  • HMDC MESSAGE DISCRIMINATION
  • HMRT MESSAGE ROUTING
  • FIG. 16a The behavior of the processes among one another and with the adjacent layers SCCP 1607 or MTP2 1609 is shown in FIG. 16a as a flow chart and in FIG. 16b as a flow chart with local process queues 1601, 1602, 1603.
  • Process HMDC 1604 receives signaling messages from level MTP2 and distributes them depending on the destination node of the messages.
  • the messages are placed in the associated process queue 1603.
  • Messages intended for the own node that is to say for the SRP, which is assigned to the MTP layer 1608, are forwarded to the process HMDT 1605. They are sorted into the corresponding process queue 1601 and transferred to the SCCP 1007 after processing by the HMDT process. If a message is destined for another node, it is passed from process HMDC 1604 to process HMRT 1606. This gives the message 43 Processing, that is after calling from the corresponding process queue 1602, to the MTP 2 1609 level. The same is good for messages that the MTP3 1608 level receives from the SCCP 1607.
  • the FIFO queues 1601, 1602, 1603 used in FIG. 16b are able to receive several signaling messages and to process them one after the other.
  • the order of execution is determined by the respective delay time and is entered in the local event calendar of the SRP or SS7 simulator.
  • FIG. 17 shows the modeling of the TCAP layer of the SS7 as a further example.
  • the TCAP layer 1702 is arranged between the layer of the SS7-USER 1701 and the SCCP layer 1703.
  • the message flows between the layers as well as within the TCAP layer 1702 are indicated by Pfeüe.
  • four processes are simulated in the TCAP layer 1702, the processes INVOCATION STATE MACHINE 1704, COMPONENT COORDINATOR 1705, DIALOG HANDLING 1706 and TRANSACTION SUB-LAYER 1707.
  • a process queue 1708 to 1711 is assigned to each of these processes.
  • a follow-up process of the same layer is called in accordance with the message flow shown here, or the message is forwarded to the SS7 layer above or below it.
  • the process sequences are user-definable and can be flexibly adapted to the real process flow within a TCAP layer.
  • Figure 18 shows an example of configuration parameters of the SS7 simulator.
  • the process times for the processes involved in the communication between SSP and SCP can initially be specified for the individual SS7 layers.
  • the process sequence in the SS7 layers, as with the SCP simulation, the service processing program can be defined by the user and can thus be flexibly adapted to the real conditions. A certain priority can also be assigned to the individual processes, which is not shown here. 44
  • the user-definable parameters relate to the topology of the intelligent network in the area of the SS 7, e.g. the number of SCPs, the number of character channels between SSP and STP and between STP and SCP, the delay due to the delay of a message between STP and SSP or SCP and the delay between the processors.
  • the message length can also be specified.
  • FIG. 19 shows the implementation of the overload protection simulator 1903 in the IN simulator in online operation and its principle of operation.
  • the overload protection simulator 1903 regulates the amount of traffic generated or passed on by the traffic simulator 1902 on the basis of system data that allow a statement about the current load situation, in particular of the SCP simulator, managed by the online simulator 1901 and the overload protection simulator 1903 be transferred via the online interface.
  • the overload protection simulator 1903 regulates the amount of traffic generated or passed on by the traffic simulator 1902 according to the principle of automatic ca gapping (ACG): Within a time interval ⁇ tl (gap time), for example, only one call is made, possibly with predetermined properties , passed from the SSP to the SCP. The time interval ⁇ t2 (gap duration) indicates how long such a reduction measure lasts.
  • ACG automatic ca gapping
  • the overload protection simulator 1903 (overload process) is called by the traffic simulator 1902. He transfers a call with the corresponding parameters, such as service, message, SSP identification number, time. In addition to this data, the overload process receives the current system data, such as CPU utilization, response times and queue length, from online simulator 1901.
  • the overload process which has been initialized, is controlled with the aid of its own counters and the transferred system data. There can be a separate counter for each SSP, service and / or service class. After the call has been recorded in the corresponding counter, the overload protection 45 Simulator the current overload level using the system data. Then the gap parameters for the current overload level are read from the initiation table.
  • the initialization table Ue is stored in the initiation file which is called up when the overload protection simulator 1903 is started.
  • the gap parameters are, for example, the time interval ⁇ tl (gap time), within which only one call, possibly with certain properties, is passed from the SSP to the SCP, and the time interval ⁇ t2 (gap duration), which indicates how long such a time Reduction measure continues.
  • calls are counted within a predeterminable time window and, if necessary, time-weighted.
  • the weighting preferably depends exponentially on the age of the call, with a younger call being weighted more than a previous call.
  • the load is also increased on the SSPs or on the services in order to be able to simulate service and / or SSP-dependent overload protection, in which calls with certain properties are selectively suppressed.
  • Different overload levels can be defined by the user, to which user-defined gap parameters are assigned.
  • the gap measures are updated accordingly, e.g. adjusted the length of the time interval ⁇ tl or ⁇ t2. It is then checked whether the current call is such
  • the process to be called is then passed the return value TRUE or another identifier, otherwise the value FALSE or another identifier assigned to it.
  • FIG. 20 shows the implementation of the overload protection simulator 2002 in the IN simulator in file mode.
  • file mode the calls are generated beforehand with the traffic simulator and stored in a transfer file 2001. Since no current system data can be transferred to the overload protection simulator 2002 in file mode, it itself measures the current load in the form of calls per unit of time. The current load is compared to a predetermined value for the maximum number of calls made by the traffic simulator; this is stored, for example, in the initiation file. The current overload level is calculated from the current incoming load and the maximum outgoing load.
  • the new defense parameters are then read from the initiation table and the defense measures updated.
  • FIG. 21 shows an example of those determined with the IN simulator
  • Simulation data It was based on the configuration that results from the configuration files shown there according to FIGS. 6, 11 and 18.
  • the SS7 simulator is active while the overload protection simulator is switched off.
  • Telephone traffic of 30 calls per second was specified in the time interval 0 to 500 seconds.
  • Figures 21.a to c show the data on network statistics determined by the simulator.
  • the preselected average telephone traffic and the telephone traffic generated by the traffic simulator are each represented as a function of the simulation time.
  • the configured telephone traffic is shown in dashed lines and corresponds to the above-mentioned specifications, i.e. in the interval 0 to 500 seconds is a constant 30 calls per second, then 0 calls per second.
  • Figure 21.b shows the SCP response time in seconds as a function of the simulation time. With constant telephone traffic of approx. 30 calls per second, the simulation results in a steady state, ie the SCP processes the requests directed to it with a response time of 0.4 to 0.7 seconds.
  • Figure 21.c shows the number of messages that are in the SCP simulator for processing as a function of the simulation time. As expected, the number of calls in the SCP and the response time of the SCP are strongly correlated.
  • Figures 2 l.d-f show SCP statistical data as a function of time, namely the utilization of the CPUs in%, the number of messages in a CPU queue and the number of processes processed by one CPU per unit of time. The maximum, minimum and average CPU utilization, queue length and number of dispatches are shown.
  • the number of messages that are currently being processed in the SCP varies according to FIG. 21. c on average between 20 and 60, while there are only an average of 6 messages in the queue, FIG. 21.e. From these values, as well as from the average CPU utilization of 80%, it can be seen that the SCP can handle a traffic volume of 30 calls per second without problems with the selected configuration.
  • Figures 21.g-i show SS7 statistics.
  • Figure 2 g corresponds to 2 a and shows the bagged or generated telephone traffic as a function of
  • Figure 21.h shows the delay of a message in the SS7 simulator on the way from the SSP to the SCP (dashed) as a function of time, and the delay of a message on the way from the SCP to the SSP (dotted).
  • Figure 21i shows the number of messages in the SS7 in the direction of SCP (dashed) or in the direction of SSP (dotted) as a function of
  • Figure 2l.j shows the SSP statistics as a function of time, i.e. the number of lines to and from SSP1 or SSP2 (left or right
  • FIG. 22 shows a further example of simulation data determined with the IN simulator, here in the case of a strongly changing traffic volume. Traffic was changed every 100 seconds by 48 40 on 20, on 80, on 10, on 50 and on 5 calls per second. The SS7 simulator is active while the overload protection is inactive. The assignment of the curves to the simulated variables corresponds to that in FIG. 21.
  • the simulation shown in FIG. 22 leads to sharp increases in the SCP response time as soon as the limit of 30 calls per second is exceeded.
  • the number of calls in the SCP and the SCP queue length are also increasing rapidly.
  • the SCP is able to process the waiting messages, so that the delay time and also the length of the queue decrease.
  • the processing time of the messages in the central signaling system fluctuates by only 0.02 seconds despite the different traffic volumes.
  • FIG. 23 shows a simulation with the same congested traffic volume as in FIG. 22, but here with an overload protection simulator activated.
  • the overload protection simulator was given a maximum traffic volume of 30 calls per second.
  • the limitation of the generated traffic volume to these average 30 calls per second is visible in FIG.
  • the response time of the SCP, FIG. 23b is therefore reduced to a value of approximately 0.4 to 0.5 seconds, which corresponds to the SCP response times determined in the example of FIG. 21 for a constant traffic volume of 30 calls per second.
  • the response times are therefore a factor 100 shorter than in the example in FIG. 22.
  • the IN simulator according to the invention is a useful tool in all stages of planning and the operation of an intelligent communication network to test the performance of the network, to adapt it to specific requirements and to detect weaknesses. Due to the great flexibility of the simulation modules, it is easy to adapt to existing as well as future realities. By comparing with simulated values and the parameters on which the simulation is based, it is possible to choose the configuration of the real intelligent network in such a way that the best possible efficiency of the IN is achieved under the given boundary conditions. This leads to considerable cost savings in the operation and planning of intelligent networks, since with the help of the EN simulation, the optimal configuration of the intelligent network and its components can be determined and implemented directly in reality without the need for expensive experimentation times at the real IN.
  • the IN simulator is a suitable tool for determining management parameters, which can, for example, provide a stable basis for problematic overload protection.
  • the results of the simulation also enable the development and review of general global or network node-related management functions that can be reacted and used more effectively than the previously used overload protection mechanisms.
  • SCP input processor 104 telephone user channels 105 SS7 channels 106,107,108 SCP 109 traffic simulator 201,301,401, 1902 SCP simulator 202,302,402 SS7 simulator 303,403,503 transfer files 203,204,304,305,306,307,
  • Protocol files 417-420 File name file 421

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Erfindung betrifft einen Simulator zur Simulation der Performance eines Intelligenten Netzwerks (IN), der folgende Komponenten aufweist: 1. ein Modul (201, 301, 401) zur Simulation beliebiger IN-typischer Ereignisfolgen (Verkehrssimulator) nach den Regeln der Verkehrtheorie; 2. einem Modul (202, 302, 402) zur ereignisorientierten Simulation des Service Control Point (SCP-Simulator) unter Verwendung von Prozeßmodellen; 3. Mittel (203, 204, 304-307, 406-409) zur Datenübergabe zwischen den Modulen; 4. Mittel (207, 311, 416, 208-212, 312-317, 411-415) zur Eingabe und Speicherung der Netzkonfiguration, Kommunikationsdienstespezifikation und sonstigen Simulationsparametern sowie deren Übergabe an die entsprechenden Module; 5. Mittel (205-207, 308-310, 417-420, 423) zur Ausgabe und/oder Speicherung der simulierten Daten. Weiterhin sind Module (303, 403, 503, 404, 502) zur Simulation des SS7-Zeichengabesystems, vorzugsweise unter Berücksichtigung der Funktionalitäten des Service Relay Points (SRP) (103), sowie von Überlastabwehrmechanismen innerhalb des IN vorgesehen. Die Simulationsmodule kommunizieren in einem Datei-Modus über Übergabedateien oder sind in einem Online-Modus durch ein gemeinsames Organisationsprogramm, den Online-Simulator, verknüpft. Zentrale Elemente des Simulators im Online-Modus sind Ereigniskalender, in denen von den Simulationsmodulen abzuarbeitende Ereignisse in der Reihenfolge ihrer Bearbeitung eingetragen sind und die die Umsetzung in der Realität parallel ablaufender Prozesse in eine sequentielle Bearbeitung ermöglichen. Mit dem erfindungsgemäßen IN-Simulator kann die Performance eines IN in gegenwärtiger und zukünftiger Realisierung vorteilhaft ermittelt werden, um Schwachstellen aufzuspüren und die Effizienz des IN zu steigern.

Description

1 Simulator zur Simulation eines Intelligenten Netzwerks
Technisches Gebiet:
Die Erfindung betrifft einen Simulator zur Simulation eines Intelligenten Netzwerks, insbesondere zur Auffindung und Analyse von Schwachstellen, zum Testen von Netzkonfigurationen und/oder Steuerungsmechanismen sowie zur Auffindung von Möglichkeiten zur Steigerung der Leistungsfähigkeit des Netzes.
Hintergrund der Erfindung:
Der Begriff Intelligentes Netz (IN) steht weltweit für das Konzept einer für alle Telekommunikationsnetze gültigen Netzarchitektur. Kernelement dieses Konzepts ist ein softwaredefiniertes individuelles Kommunikationsprofil für die Kunden der Telekommunikations dienste. Im IN sind wichtige Funktionen und Daten zentralisiert und werden nur in einem oder wenigen Knoten bereitgestellt. Diese Funktionen und Daten betreffen beispielsweise Informationen, wie ein Anruf mit einer IN-spezifischen Rufnummer in Abhängigkeit von seinem Ursprungsort, der angewählten Rufnummer, der Tageszeit und/oder sonstigen Parametern behandelt werden soll, z.B. ob und an welchen Netzteilnehmer ein Anruf weitervermittelt, ob und auf welche Ansagen ein Anruf geschaltet werden soll oder ob ein Anruf lediglich gezählt wird. Mit Hilfe des Intelligenten Netzes wird ein intelligenter, verzweigter Datenbankzugriff von einer Mehrzahl von Dienstzugangspunkten (Service Switching Point, SSP) auf in einem oder wenigen zentralen Knoten (Service Control Point, SCP) zur Dienstesteuerung abgelegte Daten und Funktionen realisiert.
Das Intelligente Netz liegt dabei organisatorisch als zentralistisches Netz über dem Telefonnetz und stellt Intelligenz zum Auf- und Abbau von Verbindungen über das Telefonnetz zur Verfügung. Die Schnittstelle zwischen Telefonnetz und Intelligentem Netz ist dabei durch die SSPs gebildet, bei welchen Anrufe mit IN-spezifischen Rufnummern eingehen und nach Erhalt der Weiterbehandlungsinformation vom SCP gemäß dieser Anweisungen weiterbehandelt werden, z.B. an eine vom SCP mitgeteilte Rufnummer weitervermittelt werden. 2 Im Intelligenten Netz werden die einzelnen Funktionskomplexe in separaten Systemebenen realisiert. IN -Transport- und Vermittlungsfunktionen werden in der SSP-Ebene (Service Switching Point) realisiert, Dienstesteuerungsfunktionen und Verwaltung der Dienstdaten in der SCP- Ebene (Service Control Point) und Diensteverwaltungen im Service
Management System (SMS). Die Kommunikation zwischen der SSP- und der SCP-Ebene erfolgt über das Zeichengabesystem Nr. 7 (SS7-System), über welches IN-spezifische Nachrichten zur Anrufbehandlung verschickt werden. Der Zeichengabetransfer und dessen Steuerung innerhalb des SS7-Systems wird durch einen oder mehrere Service Transfer bzw. Relay Point (STP bzw. SRP) realisiert. Der STP bzw. SRP dient dabei zur Vermittlung und Verteilung (Routing) der Nachrichten im zentralen Zeichengabekanal zwischen dem SCP und dem SSP. Der STP bzw. SRP kann zudem als Gateway für Nachrichten dienen, die IN-Dienste eines anderen Netzbetreibers betreffen und vom SCP eines weiteren IN bearbeitet werden müssen. Wichtiges
Routing-Kriterium einer IN-Nachricht ist ihr globaler Titel (global title); die STP/SRP-Ebene realisiert dabei die Global Title Translation (GTT).
Die SSP-Ebene verfügt über Möglichkeiten, IN- Verbindungen zu erkennen, z.B. anhand der Rufnummer, und zu unterstützen. Bei diesen Verbindungen müssen Informationen bei einem SCP für den weiteren Verbindungsaufbau abgefragt werden. Der SCP enthält Programme und die dazugehörigen Daten zur Steuerung der Dienste. Desweiteren sammelt der SCP Daten zur Vergebührung und zu statistischen Auswertungen. Mehrere SSP greifen auf einen zentralen SCP zu. Dem SCP übergeordnet ist das Service Management System, welches die Administration der IN-Dienste und IN-Komponenten enthält.
Mit Hilfe eines Intelligenten Netzes werden beispielsweise folgende IN- Dienste realisiert:
Televotum (TV): Der Dienst Televotum ermöglicht dem Dienstteilnehmer, die Anzahl der Anrufe unter seiner Televotum-Rufnummer registrieren zu lassen. In einer Variante dieses Dienstes erfolgt eine Anfrage an den SCP bei jedem Anruf, in einer weiteren Variante werden die Anrufe im SSP vorgezählt, wobei eine Anfrage an den SCP bei jedem k-ten Anruf erfolgt. Unabhängig von der gewählten Variante wird jeder im IN-System eintreffende TV-Ruf registriert. Dabei kann in Abhängigkeit vom aktiven Verkehrsführungsprogramm zudem 3 jeder n-te Ruf speziell behandelt werden, z.B. nach der Registrierung zu einer vom Dienstteilnehmer festgelegte Zieladresse weitergeleitet werden. Alle anderen Anrufe führen nach der Registrierung zu einer Ansage, die ebenfalls im Verkehrsfuhrungsprogramm vom Dienstteilnehmer festgelegt wurde.
Freephone (FPH): Der Dienst Freephone gibt Dienstnutzern die Möglichkeit, den "Dienstteilnehmer" gebührenfrei anzurufen. Die gesamten Gebühren werden vom Dienstteilnehmer übernommen.
Universelle Ruf ummer (UNU): Mit dem Dienst Universelle Rufnummer ist es möglich, daß ein Dienstteilnehmer unter einer einheitlichen, ortsnetzunabhängigen Rufnummer überall erreichbar ist. Die Gebühren für derartige Verbindungen können abhängig von der Festlegung des Dienstteilnehmers vom Anrufer allein oder aufgeteilt auf Anrufenden und Angerufenem erhoben werden.
Tele-Info-Service (TIS): Der Tele-Info-Service ermöghcht Anrufern den Zugang zum Informationsangebot des Dienstteilnehmers über dessen Ansageeinrichtungen oder in direktem Dialog. Die Gebühren werden dem Anrufer berechnet und können anhand der verbindungsbezogenen
Informationen zwischen Netzbetreiber und Dienstteilnehmer aufgeteilt werden.
Darüberhinaus sind weitere Dienste möglich, z.B. Zuweisung einer Rufnummer zu einem Kunden anstelle zu einem Anschluß und Leitung aller Anrufe mit dieser Rufnummer an den Aufenthaltsort des Kunden. In diesem Sinne sind auch Mobilfunknetze Intelligente Netze.
Der Dienstteilnehmer hat die Möglichkeit, seinen Dienst anhand weiterer Dienstmerkmale zu spezifizieren, z.B.
Anruf -Umlenkung (Rerouting): Wenn sich der angewählte Teilnehmer nicht meldet oder die Nummer besetzt ist, wird der Anruf entweder auf eine Ansage oder auf eine andere Nummer durchgeschaltet. Dieser Vorgang kann bis zu einer vorgeschriebenen Anzahl von Versuchen wiederholt werden, ansonsten wird der Anruf abgewiesen.
Anrufbegrenzung: Übersteigt die Anzahl der Anrufe zu einer Ziehrufhummer innerhalb eines Zeitraums die vom Dienstteilnehmer vorgegebene 4 Begrenzung, werden die überzähligen Anrufe auf definierte alternative Zielrufnummern oder Ansagen geführt.
Zeitabhängige Zielansteuerung: Der Anrufszeitpunkt wird gegen die periodischen und/oder temporären Zeitfenster geprüft. Wird kein gültiges Zeitfenster gefunden, führt der SCP den IN -Anruf zu einer Standardhinweisansage, ansonsten wird zum Anrufziel oder zum nächsten Dienstmerkmal verzweigt.
Ursprungsabhängige Zielansteuerung: Die Netzursprungsrnformation wird mit der im Verkehrsfuhrungsprogramm hinterlegten Ursprungsinformation verglichen. Wird keine Übereinstimmung gefunden, führt der SCP den Anruf zu einer Standardhinweisansage, ansonsten wird zum Anrufziel oder zum nächsten Dienstmerkmal verzweigt.
Anrufverteilung: Das Dienstmerkmal Anrufverteilung erlaubt die Definition individueller Quoten, nach denen Anrufe auf verschiedene Ziele verteilt werden.
Wird ein Anruf auf eine Ansage geschaltet, fungiert der SSP als fiktiver Kommunikationsteilnehmer. Der SSP unterstützt netzleistungsbezogene Standardhinweisansagen und Ansagen, die als Anrufsziel angesteuert werden können. Die einzelnen Ansagen haben eine begrenzte Zahl von Abfrageplätzen. Bei Belegung aller Abfrageplätze werden die überzähligen Anrufe abgewiesen. Jede Ansage ist durch eine maximale Abhörzeitdauer und Anzahl von Wiederholungen begrenzt.
Für die meisten IN-Dienste, z.B. FPH, UNU, TIS und TV ohne Vorzählung, besteht die Aufgabe des Intelligenten Netzes darin, die gewählte IN-Nummer in Abhängigkeit von definierten Dienstparametern im
Verkehrsführungsprogramm in eine reale Nummer zu übersetzen. Dieses erfolgt nach folgendem prinzipiellen Ablauf:
1. Im SSP werden die ersten Ziffern der gewählten Telefonnummer ausgewertet und der IN-Dienst erkannt. Der SSP sendet eine Anfrage zur weiteren Rufbehandlung mit der Nachricht PROVTDE INSTRUCTION an den SCP. Die Nachricht enthält als Parameter die vom Dienstnutzer gewählte IN- 5 Teilnehmerrufhummer (CALLED-PARTY-ADDRESS) und die Rufiiummer des Anrufes (CALLING-PARTY-ADDRESS).
2. Im SCP wird durch die Nachricht PROVTOE-INSTRUCTION das
Dienstlogikprogramm für den entsprechenden IN-Dienst angesprochen. Das über CALLED-PARTY-ADDRESS adressierte teilnehmerspezifische Verkehrsführungsprogramm wird angesteuert. Als Ergebnis wird im hier beschriebenen Normfall ein Ziel für den Verbindungsaufbau ermittelt, das kann eine Rufnummer oder eine Ansage sein. Zusätzlich können sich aus dem Verkehrsführungsprogramm Anforderungen zur Verbindungsüberwachung ergeben, wie das Überwachen von "Teilnehmer besetzt" und "Teilnehmer antwortet nicht". Der SCP sichert die Ergebnisse im verbindungsspezifischen Kontext und sendet die Nachricht CREATE-JOIN und MONITOR an den SSP. Die Nachricht enthält als Parameter CALLED-PARTY-ADDRESS und EVENTLISTE, die die zu überwachenden Ereignisse spezifiziert.
3. Im SSP wird zu der mit CREATE-JOIN übergebenen Zielrufhummer über das Fernsprechnetz ein Verbindungsaufbau zum B-Teilnehmer durchgeführt oder auf eine Ansage geschaltet.
4. Der SSP überwacht den Verbindungsaufbau zum B-Teilnehmer, wenn dies in der EVENTLISTE spezifiziert wurde. Wenn der B-Teilnehmer nicht reagiert, wird die Verbindung in Richtung B-Teilnehmer nach Ablauf eines Timeouts ausgelöst und der SCP mit der Nachricht EVENT über das aufgetretene Ereignis informiert.
5. Aus dem Verkehrsführungsprogramm wird ein Alternativziel bestimmt (Rerouting) und eine Nachricht CREATE-JOIN und MONITOR mit entsprechenden Patametern an den SSP gesendet.
6. Im SSP wird zu der mit CREATE-JOIN übergebenen Zielrufnummer über das Fernsprechnetz ein Verbindungsaufbau zum B-Teilnehmer durchgeführt, oder auf eine Ansage geschaltet. Nach Melden des B-Teilnehmers wird die Verbindung durchgeschaltet.
7. Bei Gesprächsende werden im SSP die im SCP benötigten Daten für die Vergebührung und Statistik zusammengestellt und mit der Nachricht 6
EVENT(CALL-END) übertragen. IM SSP wird mit einem Timer die Bestätigung dieser Nachricht durch den SCP überwacht. Ist bis zum Ablauf des Timers keine Bestätigung eingetroffen, wird das Senden der Nachricht EVENT(CALL-END) wiederholt. 8. Nach Empfang der Nachricht EVENT(CALL-END) sendet der SCP eine Nachricht zum Beenden des TCAP -Dialogs. Im SCP wird der verbindungsspezifische Kontext reaktiviert. Die empfangenen Timestamps werden zusammen mit den im Kontext hinterlegten Daten abgespeichert (CallTickets). Sie werden später zur weiteren Bearbeitung an das SMS übertragen. Im SCP geführte Zähler (z.B. für erfolgreiche Anrufe) werden hochgezählt (Counter Tickets).
Die Punkte 4, 5 und 6 in diesem Ablauf treten nur bei einem Rerouting auf.
Um auch bei hohem Verkehrsaufkommen einen ordnungsgemäßen Betrieb des IN sicherzustellen, sind innerhalb des IN-Überlastabwehrmechanismen vorgesehen. Die Überlastabwehr führt dazu, daß der SSP nach bestimmten Vorgaben IN -Anrufe ohne Anfrage an den SCP abweist. Beispiele für Überlastabwehrmechanismen sind AUTOMATIC-CALL-GAPPING (ACG) oder die LEAKY-BUCKET-Methode. Es ist eine dienst- und/oder zielabhängige Überlastabwehr möglich.
Ein Service Control Point ist üblicherweise ein mehrschichtiges System mit einem Hardwarefundament und mehreren, üblicherweise drei Schichten Software. Das Hardwarefundament besteht aus einem Computer mit einem oder mehreren parallel verarbeitenden Prozessoren mit Verbindungsleitungen, Festplatten, Magnetbändern, Terminals und Druckern. Die erste Softwareschicht enthält die Systemsoftware. Die zweite Sof wareschicht (NODE-Software) enthält allgemeine Funktionen für die Service Apphcation. Die dritte Softwareschicht besteht aus der Apphcation, die die anrufeverarbeitenden Dienste unterstützt. Im Falle einer Parallelverarbeitungs-Architektur des SCP weist dieser eine Mehrzahl von Prozessoren auf, die jeweils eine in sich autarke Einheit mit CPU, Hauptspeicher, Stromversorgung und Eingabe/Ausgabe-Prozessor darstellen und untereinander mit einem Bus-System verbunden sind.
Die verschiedenen SCP-Software-Schichten enthalten neben Betriebssystemprozessen und allgemeinen, nicht unmittelbar zum 7 Betriebssystem gehörenden Prozessen, z.B. zur Kommunikation zwischen den Prozessen oder zur effektiven Verwaltung des lokalen Cache, Applikationsprozesse, die für die Abarbeitung einer IN-Nachricht benötigt werden. Eine am SCP ankommende IN-Nachricht durchläuft somit in verschiedenen Schichten des SCP eine Folge von Prozessen, welche in der Generierung einer IN-Nachricht des SCP an den SSP als Antwort auf dessen Anfrage zur Anrufbehandlung resultiert. Die Prozesse können dienstund/oder diensteteilnehmerabhängig sein oder unabhängig davon von sämtlichen IN-Nachrichten genutzt werden. Die Prozesse sind in einer oder mehreren Inkarnationen auf allen bzw. ausgewählten Prozessoren eines SCP implementiert.
Die Abarbeitung einer IN-Nachricht im SCP erfolgt in der Regel nach folgendem Schema, realisiert durch Aufruf einer vorbestimmten Kette von Einzelprozessen:
Eine Nachricht vom SSP wird empfangen und an den SCP -Rechner weitergeleitet. Der SCP-Rechner empfängt die Nachricht, Speicher wird vom zur Verfügung gestellt und die Nachricht wird auf ihren Gültigkeitsbereich überprüft. Der Kontext zur Anrufbehandlung wird erstellt. Ein Routingtree wird aus dem Arbeitsspeicher oder von der Festplatte geladen. Aus dem Routingtree wird die anzuwählende Rufiiummer ermittelt. Der Kontext zum Anruf wird gespeichert und eine Antwort an den SSP erstellt. Die -Antwort wird als neue IN-Nachricht an den SSP gesendet.
Alle zur Verarbeitung eines IN-Rufs benötigten Prozesse werden nur auf einen Prozessor angestoßen, wobei der vorhergehende Prozeß terminiert sein muß, bevor der nächste Prozeß angestoßen werden kann.
Die Verbindungsende-Behandlung nach Auslösung der Verbindung von der Vermittlungsstelle zum SSP durch den Anrufer wird analog zur oben dargestellten Verbindungsaufbaubehandlung durch eine entsprechende Prozeßkette abgearbeitet.
Die Abarbeitung einer IN-Nachricht im STP/SRP erfolgt ebenfalls durch Abarbeitung einer vorbestimmten Kette aufeinanderfolgender Prozesse.
Technische Aufgabe: 8
Bei Messungen an existierenden IN-Netzwerken, insbesondere an deren zentraler Komponente SCP, wurden hohe mittlere Bearbeitungszeiten beobachtet. Dieses führt zu inakzeptabel langen Verbindungsaufbauzeiten bei hoher Auslastung des Systems durch IN-Verkehr, insbesondere zu Spitzenzeiten des Dienstes Televotum, aber auch durch andere Einflüsse. Die Analyse von Schwachstellen des IN-Netzes, die zu solchen erhöhten Antwortzeiten fuhren, ist jedoch problematisch, da die Meßwerte jeweils nur statistische Daten sind und eine Messung nicht in jedem Stadium der Nachrichtenbearbeitung vorgenommen werden kann. Weiterhin besteht auch ein grundsätzliches Problem bei der Messung am realen IN dergestalt, daß alle realen Detailmessungen die Performance des zu untersuchenden Systems durch Aktivierung zusätzlicher Meßprozesse, die nicht zur regulären IN-Call- Behandlung gehören, beeinflussen.
Ein weiteres Problem ergibt sich bei der Implementierung neuer Komponenten in ein bestehendes IN. Das IN befindet sich zu jedem Zeitpunkt im Betriebszustand, wobei eine Parameteränderung an diesem komplexen System ohne Gefährdung der Betriebssicherheit nicht möglich ist. Es ist weiterhin gegenwärtig nicht feststellbar, ob beispielsweise Prozessoren mit einer bestimmten technischen Spezifikation tatsächlich die vom Hersteller zugesicherten Leistungen bringen.
Neben der Notwendigkeit, Schwachstellen schon bestehender Intelligenter Netze zu analysieren, besteht ein Bedürfnis dahingehend, auch noch nicht realisierte Netzkonfigurationen bereits im Planungsstadium zu testen, um innerhalb gegebener Randbedingungen die Konfiguration mit der bestmöglichen Performance zu ermitteln. Es stellt sich beispielsweise die Frage, welche Leistungsfähigkeit der SCP-Rechner bzw. dessen
Einzelprozessoren haben müssen oder welche Kapazitäten ggf. in welcher Form für die einzelnen Dienste bereitgestellt werden müssen. Weiterhin stellt sich die Frage, ob und wie möglicherweise durch eine geänderte Prozeßverwaltung innerhalb der Prozessoren des IN eine bessere Performance erzielbar ist. Ein weiteres kritisches Element beim Betrieb eines InteUigenten Netzes ist auch der Überlastabwehrschutz, der das System möglichst nahe an seiner Leistungsgrenze stabilisieren soll. Die Ermittlung entsprechender Überlastabwehrparameter ist in der Praxis nur schwer möglich, so daß das 9 Bedürfnis besteht, die optimalen Einstellungen der Überlastabwehr in Abhängigkeit von sonstigen Netzkonfigurationen unabhängig vom Netzbetrieb zu ermitteln und auf das reale Netz zu übertragen.
Der Erfindung hegt daher die Aufgabe zugrunde, ein Werkzeug zur
Ermittlung der Performance eines Kommunikationsnetzes mit IN-Struktur zur Verfügung zu stellen. Dabei soll der Benutzer die Netzkonfiguration sowie die Art der Anrufbehandlung innerhalb der Netzkomponenten in weiten Grenzen angeben und verändern können, die Simulation soll also unabhängig von der gewählten IN-Platform sein. Es sollen statistische Daten zur Performance des Netzes erzeugt werden, welche einen Vergleich an mit realen IN- Komponenten gemessenen Daten erlauben, weiterhin sollen jedoch auch solche Daten zur Verfügung gestellt werden, auf welche bei realen Netzen keine Zugriffsmöghchkeiten bestehen, so etwa ruf spezifische Protokollierung der Bearbeitungszeiten beim Durchlauf des Intelligenten Netzes.
Offenbarung der Erfindung und deren Vorteile:
Die Lösung der Aufgabe besteht erfindungsgemäß bei einem Simulator zur Simulation der Performance eines Intelligenten Netzwerks (IN), der folgende Komponenten aufweist:
1. Ein Modul zur Simulation behebiger IN-typischer Ereignisfolgen (Verkehrssimulator) nach den Regeln der Verkehrstheorie; 2. einem Modul zur ereignisorientierten Simulation des Service Control Point (SCP-Simulator) unter Verwendung von Prozeßmodellen;
3. Mittel zur Datenübergabe zwischen den Modulen;
4. Mittel zur Eingabe und Speicherung der Netzkonfiguration, Kommunikationsdienstespezifikation und sonstigen Simulationsparametern sowie deren Übergabe an die entsprechenden Module;
5. Mittel zur Ausgabe und/oder Speicherung der simuherten Daten.
Da die Ursachen für die Performancedefizite des Intelligenten Netzes aufgrund dessen zentralistischer Struktur häufig im zentralen SCP zu suchen sind, bildet die Modellierung des SCP des Kernstücks des Simulators. Mittels Warteschlangenmodellen/Prozeßmodellen ist eine detaillierte Modellierung der Softwarestruktur des SCP realisierbar. Ein weiteres Modul, der 10 Verkehrssimulator, wird im IN-Simulator benötigt, um IN-spezifische Last zu generieren und realistischen Input für den SCP-Simulator zu erzeugen.
Der Simulator ist im Kern durch ein Computerprogramm realisiert. Dieses Programm greift beim Start oder während der Simulation auf Dateien zu, in welchen Parameter zur Konfiguration des Netzes bzw. der Netzkomponenten, zur Spezifikation der Kommunikationsdienste, d.h. Art und Ablauf der Anrufbehandlung, sowie sonstige den Simulationsablauf betreffende Parameter, z.B. Angaben über das Verkehrsaufkommen, gespeichert sind. Diese Dateien sind vom Benutzer in bekannter Weise beschreibbar und veränderbar. Vorzugsweise erfolgt die Eingabe der Simulationsparameter unter Verwendung von Büdschirm und Tastatur eines Computers. Die Simulationsparameter werden gespeichert und können vor Durchlauf einer neuen Simulation einzeln oder in ihrer Gesamtheit verändert werden, so daß gezielt der Einfluß einzelner Parameter auf die simulierte IN-Performance zu analysieren ist.
Die verwendete Simulationsart entspricht der sogenannten ereignisgesteuerten Simulation. Für spezielle Zeitpunkte, werden IN- spezifische Ereignisse generiert, die zur Bearbeitung die einzelnen Komponenten des Simulators durchlaufen. Die in den einzelnen Simulationsmodulen, ggf. auch in Unterkomponenten der Simulationsmodule, anfallenden Bearbeitungszeiten werden mitprotokolliert.
Vorzugsweise weist der IN-Simulator zusätzlich zu den Basiskomponenten SCP-Simulator und Verkehrssimulator ein Modul zur ereignisorientierten Simulation des Zeichengabesystems Nr. 7 auf. Dieser SS7-Simulator arbeitet auf der Basis von Warteschlangenmodellen, soweit Funktionalitäten in das SS7 integrierter Prozessoren nachgebildet werden sollen, und/oder prägt einer Nachricht lediglich eine konstante Verzögerungszeit auf, welche die endliche Laufzeit in den Zeichengabekanälen zwischen SSP und SCP berücksichtigt. Die innerhalb des SS7-Simulators zu simulierenden Komponenten sind die Prozessoren/Prozeßketten in der SSP-Ebene, der STP/SRP-Ebene und je nach Netzkonfiguration der SCP-Ebene, z.B. ein SCP-Eingangsprozessor (FRONT END SYSTEM), welcher die Schnittstelle des SCP zum Zeichengabesystem bildet. 11 In einer weiteren vorteilhaften Ausführung der Erfindung ist ein Modul zur Simulation von Überlastabwehrmechanismen vorgesehen. Dieser Überlastabwehr-Simulator modifiziert die Anzahl der von wenigstens einem der übrigen Simulisationsmodulen verarbeiteten Ereignisse in Abhängigkeit von der Belastung eines oder mehrerer Simulationsmodule, z.B. in Abhänigkeit von der Warteschlangenlänge, und/oder von benutzerdefinierbaren Parametern. Die benutzerdefinierbaren Parameter sind beispielsweise Belastungsgrenzen, bei deren Überschreitung die Überlastabwehr aktiviert wird. Anstatt fest definierter Grenzen kann auch eine "unscharfe" Entscheidung vorgesehen sein, z.B. mittels einer Fuzzy- Logik. Realen Verhältnissen am ehesten entsprechend ist ein Überlastabwehr-Simulator, welcher seine Steuerungsparameter vom SCP- Simulator erhält, auf den Verkehrssimulator zugreift und die Menge der vom VerkehrsSimulator erzeugten oder weitergegebenen IN-Ereignisse in Abhängigkeit von den Steuerungsparametern reguhert. Bei Eingreifen der Überlastabwehr wird ein vom Verkehrssimulator zunächst erzeugter Anruf mit einer gewissen Wahrscheinl chkeit nicht in ein IN- Ereignis, das einer Anfrage des SSP an den SCP entspricht, umgewandelt, also nicht an die weiteren Simulationsmodule weitergegeben. In der Realität entspricht dies einem vom SSP abgewiesenen Anruf.
Vorzugsweise bildet der Überlastabwehr-Simulator den Mechanismus des Automatic Call Gapping (ACG) nach. Dabei werden innerhalb eines bestimmten Zeitintervalls sämtliche über eine bestimmte Anzahl hinausgehenden Anrufe/Ereignisse abgewiesen.
Die Module Verkehrssimulator, SCP-Simulator sowie gegebenenfalls SS7- Simulator und Überlastabwehrsimulator stellen eigenständige Simulatoren der entsprechenden Netzkomponenten dar. Intern sind ihre Funktionen entweder über Dateien verknüpft (Datei-Modus) oder vorzugsweise über ein Organisationsprogramm integriert (Online-Modus), das die Abarbeitung der einzelnen IN-Ereignisse über alle Komponenten des IN-Simulators hinweg gewährleistet.
Im Datei-Modus erfolgt die Kommunikation zwischen den
Simulationsmodulen in Form von Schreib- bzw. Lesezugriffen auf Dateien, in denen Daten bezüglich der Konfiguration des Netzes bzw. der zu 12 simulierenden Netzkomponenten sowie ggf. die von einem der Simulationsmodule erzeugten Daten hinterlegt sind.
Um eine vollständige Simulation des Netzes durchzuführen, müssten die Teilsimulationen nacheinander aufgerufen werden. Ein Simulationslauf beginnt mit der Generierung des Verkehrsaufkommens am IN durch den Verkehrs-Simulators. Die generierten Nachrichten (PROVIDE INSTRUCTION mit ihrer Erzeugungszeit tl werden EVENT oder CALL END) in einer ersten Übergabedatei gespeichert und von dem anschließend aufzurufenden Simulationsmodul eingelesen. Es ist weiterhin zu jeder
Nachricht eine Anruf-Identifikationsnummer gespeichert, die die Zuordnung mehrerer Nachrichten zu einem Anruf und damit letztendhch die Bestimmung von ruf spezifischen Antwortzeiten erlaubt. In der einfachsten Version des Simulators ist dieses zweite Simulationsmodul der SCP-Simulator. Bei Berücksichtigung des SS7 wird die erste Datei hingegen an den SS7- Simulator übergeben. In diesem Fall werden die Nachrichten nach dem Durchlaufen des SS7-Simulators, ergänzt um den SS 7- Ausgangszeitpunkt t2, in eine zweite Übergabedatei geschrieben, auf weiche der SCP-Simulator zugreift. Der SCP-Simulator erzeugt zu jedem in der ihm übergebenen Datei vorhandenen Eintrag eine Nachricht CREATE-JOIN oder CALL END und schreibt diese mit der Ausgangszeit t3 in eine dritte Datei. Vor der Ankunft der Nachricht in SSP wird ggf. nochmals der SS7-Simulator durchlaufen, wobei der SS7- Ausgangszeitpunkt t4 protokolliert wird.
Aus den Übergabedateien der Simulationsmodule können durch
Differenzbildung der protokollierten Zeitmarken die Verzögerungszeiten in den einzelnen Netzkomponenten sowie im gesamten Netz ermittelt werden.
Da durch den sequentiellen Betrieb der Teilsimulationen jede Form von Rückkopplungen zwischen den Netzkomponenten ausgeschaltet wird, müssen mehrere Durchläufe des oben beschriebenen Vorganges erfolgen, um einen eingeschwungenen Zustand zu erhalten die Funktionalitäten des realen Netzes weitgehend nachzubilden.
Der Dateibetrieb eignet sich sehr gut, um das Verhalten einzelner Netzkomponenten getrennt vom Netz, also rückkopplungsfrei, zu untersuchen. Das Verhalten der einzelnen Komponenten läßt sich z.B. durch Modifikation der entsprechenden Simulationsparameter schnell und direkt 13 ermitteln. Dabei sind einzelne IN-Komponenten getrennt modifizierbar und analysierbar. Der Dateimodus gestattet zudem, einzelne EVENTS zwischen den Komponenten leicht zu verfolgen. Das stationäre Verhalten des Gesamtsystems läßt sich jedoch im Dateimodus nur iterativ mit geeigneten Anfangsbedingungen ermitteln.
Im Online-Modus sorgt ein Organisationsprogramm dafür, daß die Teilsimulationen quasiparallel ablaufen. Damit ist der Simulator imstande, das Netz als Ganzes zu simulieren und dabei insbesondere auch Rückkopplungen zwischen den Komponenten unmittelbar zu berücksichtigen. Die Umsetzung der in der Realität parallel ablaufenden Bearbeitung der Nachrichten in den Netzkomponenten in eine sequentielle bzw. quasiparallele Bearbeitung der IN-Ereignisse in den Simulationsmodulen wird mit Hilfe von Ereigniskalendern reahsiert. Ein Ereigniskalender ist eine Liste aller von einem Element, z.B dem Simulator, einem Simulationsmodul oder einer Teilkomponente eines Moduls, abzuarbeitender Ereignisse, z.B. IN-Nachrichten oder Einzelprozesse, die in chronologischer Reihenfolge in diese Liste eingetragen sind. Mit hi fe der Ereigniskalender bestimmt der Online-Simulator, welches Ereignis als nächstes zu bearbeiten ist (Ereignisorientierte Simulation). Der
Startzeitpunkt des nächsten Ereignisses ergibt sich dabei additiv aus dem Startzeitpunkt und der Dauer des vorhergehenden Ereignisses. Eine zentrale Rolle bei der Realisierung des quasiparallelen Betriebs der Simulationsmodule spielt der globale Ereigniskalender, der die von der Gesamtheit der Simulationsmodule abzuarbeitenden Ereignisse in chronologischer Reihenfolge enthält. Anhand des globalen Ereigniskalenders bestimmt der Simulator, welche Teilsimulation zu welchem Simulationszeitpunkt aufzurufen ist. Neben dem globalen Ereigniskalender existieren weiterhin lokale Ereigniskalender, die von den Simulationsmodulen geführt werden. In den globalen Ereigniskalender sind Ereignisse folgender Ereignisgruppen eingetragen:
Interne Ereignisse: Interne Ereignisse sind Verweise auf die lokalen Kalender der entsprechenden Simulationsmodule. Sie betreffen das Weiterschalten eines Simulationsmoduls um einen einzelnen Simulationsschritt.
Externe Ereignisse: Externe Ereignisse repräsentieren die Eingabe einer IN- Nachricht in eine Teilsimulation, sie stehen für Nachrichten die zwischen den 14 Simulationskomponenten verschickt werden und der Kommunikation der Si ulationskomponenten untereinander dienen.
Rufunabhängige Ereignisse: In einer Weiterbildung der Erfindung werden auch solche Ereignisse in dem globalen Kalender eingetragen, die unabhänigig von IN-Ereignissen sind und z.B. zur Simulation der Betriebssysteme in den Teilkomponenten gehören.
Alle Ereignisse veranlassen in der Regel das jeweilige Simulationsmodul zur Generierung eines Folgeereignisses, das wiederum in den globalen und unter Umständen auch in den lokalen Ereigniskalender eingetragen wird. Einige Ereignisse veranlassen nach ihrer Abarbeitung eine Protokollierung, anhand derer nachvollzogen werden kann, wie schnell eine Nachricht vom jeweiligen Simulationsmodul bearbeitet wurde.
Die Funktionalität des IN-Simulators ist für den Anwender vorzugsweise über eine Benutzeroberfläche zugänglich. Diese Oberfläche übernimmt die Verwaltung einer oder mehrerer Simulationen, indem sie Eingabemasken zur Eingabe der Simulationsparameter der einzelnen Simulationsmodule bereitstellt, die eingegebenen Daten in entsprechenden Dateien ablegt und simulationsbezogen speichert. Die Generation einer neuen Simulation wird mittels Kopieren und Modifizieren ausgewählter Parameter durch den Benutzer ermöghcht. Die Benutzeroberfläche beinhaltet eine weitgehend selbständige Dateiverwaltung des zu jeder Simulation gehörenden Systems von Konfigurations- und Ergebnisdateien. Der Benutzer hat die Möghchkeit, sich sämtliche simulierten Daten anzeigen zu lassen. Die vom Benutzer ausgewählten "Meßgrößen", z.B. Auslastung der SCP, Warteschlangenlänge im SCP, Verkehrsaufkommen im IN, werden mit Hilfe eines Grafikprogrammes aufbereitet und sind als Grafik auf dem Büdschirm eines Computers darstellbar. Vorzugsweise können die Simulationsergebnisse sowohl einer Simulation als auch unterschiedlicher Simulationen gemeinsam auf einem Büdschirm dargestellt werden. Weiterhin ist vorzugsweise über Dateifilter die Erzeugung von Ausgabefiles zur Weiterverarbeitung in anderen Programmen möglich.
Kurzbeschreibung der Zeichnung wobei zeigen:
Figur 1 Die Topologie eines Intelligenten Netzes 15 Figuren 2 und 3 Die Struktur eines erfindungsgemäßen, im Datei- Modus betriebenen Simulators
Figur 4 Die Struktur eines erfindungsgemäßen, im Datei- sowie im Online-Modus betreibbaren Simulators
Figur 5 Prinzipieller Aufbau eines IN-Simulators
Figur 6 Ein Beispiel für Konfigurationsparameter des
Verkehrs-Simulators
Figur 7 Prinzipieller Simulationsablauf im Datei-Modus
Figur 8 Prinzipieller Simulationsablauf im Online-Modus F Fiigguurr 99 Schematisch die Abarbeitung eines globalen internen
Ereignisses aus der Sicht der Online-Simulation
Figur 10 Prinzip der SCP-Simulation
Figur 11 Beispiel für Konfigurationsparameter des SCP-
Simulators F Fiigguurr 1122,, 1133 Ein der SCP-Simulation zugrundehegendes Modell der
Prozeßverwaltung einer CPU
Figur 14 Ein schematisches, objektorientiertes Modell eines SCP-
Simulators
Figur 15 Anordnung der SS7-Schichten F Fiigguurr 1166 Modellierung der MTP3 Ebene des SRP
Figur 17 Modellierung der TCAP-Schicht des SS 7
Figur 18 Beispiel für Konfigurationsparameter des SS7-Simulators
Figure imgf000017_0001
Figur 19 die Implementierung des Überlastabwehr-Simulators in den IN-Simulator im Online-Modus Figur 20 die Implementierung des Überlastabwehr- Simulators in den IN-Simulator im Datei-Modus Figuren 21, 22, 23 Beispiele für mit dem IN-Simulator ermittelte
Simulationsdaten.
Wege zur Ausführung der Erfindung:
Figur 1 zeigt die Topologie eines Intelligenten Netzes zur Darstellung des Simulationskonzeptes. Ein Intelligentes Netz weist im wesentlichen drei logische Komponenten auf, den Service Control Point (SCP) 109, den Service Switching Point (SSP) 102 sowie den Signal Transfer Point bzw. Signal Relay Point (STP bzw. SRP) 103. Die SSP-Ebene nimmmt Signahsierungsanforderungen der als extern betrachteten Kundengeräte über 16 eine der Vermittlungsstellen 101 des Telefonnetzes entgegen und betreibt den Verbindungsaufbau für solche IN-spezifischen Verbindungen.
Die SCP -Ebene enthält Prozeduren und Datenbanken zur Rufbewertung und zum Verbindungsmanagement. Diese Informationen dienen dazu, den Weg für eine Verbindung durch das Telefonnetz zu finden. Der SCP bzw. SRP übernimmt Vermittlungsfunktionen zwischen SCPs und SSPs. Die Kommunikation zwischen den Komponenten SSP, SCP und STP/SRP folgt über das Zeichengabesystem Nr. 7 (SS 7). Dazu bestehen in der Regel eine Vielzahl von Zeichengabekanälen 106, 107, 108 zwischen STP/SRP und SSP bzw. STP.
Prinzipiell können die drei logischen Komponenten SSP, SCP und STP/SRP in einem physikalischen Gerät integriert sein, z.B. in einer Vermittlungsstelle. Der Regelfall ist allerdings die in Figur 1 dargestellte pyramidenartige
Struktur des Intelligenten Netzes mit einem zentralen SCP 109 einer Vielzahl von davon beabstandeten SSPs 102 sowie einigen STR/SRP 103 als Nachrichtenknoten im SS7-System. Zwischen den Vermittlungsstellen des Telefonnetzes und des SSPs bestehen physikalische Nutzkanäle 105, über welche Telefonverbindungen aufgebaut werden können. Ein Anruf mit einer IN-spezifischen Rufnummer wird zunächst grundsätzlich an einen SSP vermittelt, welcher nach Erhalt der Weiterbehandlungsinformation von SCP die Verbindung an das jeweilige Ziel weitervermittelt. Der SSP stellt somit die Schnittstelle zwischen dem Telefonnetz und dem Intelligenten Netz dar. SSP- Funktionalitäten können auch direkt in eine Vermittlungsstelle integriert sein.
Im Rahmen der IN-Simulation wird der von den SSPs in das Intelligente Netz gelangende IN -Verkehr mit dem Verkehrssimulator simuliert, die Funktion des SCP wird mit dem SCP-Simulator modelliert, der SS7-Simulator modelliert die Funktionen der SSPs, der STPs/SRPs, der SCP- Eingangsprozessoren 104 sowie der Verbindungsleitungen zwischen diesen Komponenten. Der Anwender des Simulators hat die Möghchkeit, im Rahmen der Eingaben zur Netzkonfiguration die Netztop ologie frei zu wählen und so die Struktur des simulierten Netzes behebigen Vorgaben anzupassen. Zu den benutzerdefinierbaren Simulationsparametern gehören die Anzahl der SSPs 102, die Anzahl der STPs/SRPs 103, die Anzahl der SCP-Eingangsprozessoren 17 104 die -Anzahl der Zeichenkanäle zwischen einem STP/SRP und einem SCP bzw. einem SSP, ggf. auch die Anzahl der SCPs.
Figur 2 zeigt die Struktur eines erfindungsgemäßen, im Datei-Modus betriebenen IN-Simulators den Simulationsmodulen Verkehrs-Simulator 201 und SCP-Simulator 202. Der Verkehrs-Simulator 201 generiert gemäß den Benutzerangaben, die in Eingabedateien 208, 209, 210, 211, 212 hinterlegt sind, unter Berücksichtigung der ggf. in der Übergabedatei 204 gespeicherten Daten ein IN-spezifisches Verkehrsaufkommen, d.h. eine Folge von Ereignissen, welche IN-Nachrichten eines oder mehrerer SSPs an den SCP repräsentieren. Die Eingabendateien 208 bis 212 sind für den Anwender vorzugsweise über eine gemeinsame Benutzeroberfläche zugänglich und werden vom Verkehrssimulator 201 beim Simulationsbeginn eingelesen. Die Eingabedateien 208 bis 212 enthalten Parameter, welche jeweils unterschiedliche Aspekte der Simulation betreffen, z.B. die Netzkonfiguration im Bereich der Schnittstelle zwischen IN und Telefonnetz betreffend (Anzahl SSP), die internen Einstellungen eines SSP betreffend (Anzahl Ansageplätze pro Dienst, Zeit bis zum Timeout, Anzahl Leitungsverbindungen), das weitere Schicksal eines Anrufs betreffende Wahrscheinlichkeiten (mittlere Gesprächs- und/oder Ansagendauer, maximale Ansagendauer,
Umlenk wahrschein 1 i chkeit) , Angaben zur mittleren Anzahl Anrufe pro Zeiteinheit und Dienst für eines oder mehrere aufeinanderfolgende Zeitintervalle. Es versteht sich von selbst, daß die Anzahl der Eingabedateien 208 bis 212 willkürlich ist und beispielsweise sämtliche Benutzerangaben, auch andere Simulationsmodule betreffend, in einer behebigen Anzahl Dateien, auch einer einzigen, gespeichert sein können.
Im hier dargestellten Beispiel weist der SCP-Simulator 202 eine SCP- Eingabedatei 207 auf, in welcher Benutzerangaben bezüghch der SCP- Konfiguration gespeichert sind und die der SCP-Simulator 202 bei Simulationsbeginn einliest.
Im Dateimodus werden die Module Verkehrssi ulator 201 und SCP- Simulator 202 nacheinander betrieben. Die vom Verkehrssimulator erzeugte Ereignisfolge wird in eine erste Übergabedatei 203 geschrieben, welche die nunmehr vom SCP-Simulator 202 abzuarbeitenden Ereignisfolgen enthält. Im darauffolgenden Schritt liest der SCP-Simulator diese Übergabedatei 203 ein und arbeitet die darin abgespeicherten Ereignisse ab. Die abgearbeiteten 18 Ereignisse werden vom SCP-Simulator 202 in eine zweite Übergabedatei 204 eingetragen. Diese wird bei laufender Simulation erneut dem Verkehrs- Simulator 201 übergeben, kann aber wie auch die erste Übergabedatei 203 direkt der Auswertung zugeführt werden.
Die Übergabedateien stellen inhaltlich die Ereigniskalender des jeweiligen empfangenden Moduls dar. In den Übergabedateien 203, 204 sind die vom Verkehrs-Simulator 201 bzw. vom SCP-Simulator 202 erzeugten Daten als Datensatz gespeichert, der jeweils mindestens eine Zeitmarke, die die Erzeugungszeit der entsprechenden Nachricht am Verkehrs-Simulator bzw. am SCP-Simulator angibt, und eine Identifikationsnummer, welche die Zuordnung zweier oder mehrerer Nachrichten als zu einem Anruf gehörend erlaubt, enthält. Die Differenz beider Zeitmarken gibt die Bearbeitungszeit einer Nachricht im SCP an. Somit läßt sich mit dem in Figur 2 skizzierten Simulator die Reaktion des SCP auf ein gegebenes Verkehrsaufkommen direkt simulieren. Das Zeichengabesystem Nr. 7 wird dabei nicht berücksichtigt.
Die Simulationsmodule 201, 202 legen weiterhin statistische Daten, z.B. bezüghch der Prozessorauslastung im SCP, der Warteschlangenlänge im SCP oder der Leitungsauslastung vom und zum SSP, in Ausgabedateien 205, 206 ab. Die darin aufgezeichneten Daten stehen ebenfalls zur weiteren Auswertung der Simulationsergebnisse zur Verfügung.
Figur 3 zeigt die Struktur eines erfindungsgemäßen, im Datei-Modus betriebenen Simulators mit den Simulationsmodulen Verkehrssimulator 301, SS7-Simulator 303 und SCP-Simulator 302. Gegenüber dem Simulator aus Figur 2 ist der in Figur 3 dargestellte Simulator lediglich um das Modul SS 7- Simulator 303 erweitert. Dies hat zur Folge, daß zwischen den Modulen bei der sequentiellen Abarbeitung der Teilsimulationen nunmehr vier Übergabedateien 304, 305, 306, 307 übergeben werden.
Die Simulation des Intelligenten Netzes beginnt wie im oben beschriebenen Fall mit der Generierung eines IN-spezifischen Verkerhsaufkommens. Der Verkehrs-Simulator 301 hest dazu die Eingabedateien 312 bis 316 ein, welche den Dateien 208 bis 212 aus Figur 2 entsprechen falls vorhanden, wird auch die Übergabedatei 307 eingelesen. Die vom Verkehrs-Simulator 301 generierte Ereignisfolge wird in der ersten Übergabedatei 304 abgespeichert. Dann wird 19 der SS7-Simulator 303 aufgerufen. Dieser hest zunächst die SS7-Eingabedatei 317 ein, in welcher beispielsweise Daten bezüghch der Konfiguration des SS7- Systems gespeichert sind. Der SS7-Simulator 303 speichert die von ihm bearbeiteten Ereignisfolgen in einer zweiten Übergabedatei 305, welche vom SCP-Simulator 302 bei dessen Aufruf eingelesen wird. Die vom SCP- Simulator 302 bearbeiteten Ereignisfolgen werden dann in einer Übergabedatei 306 eingetragen. Um den Rücklauf der IN-Nachrichten vom SCP zum SSP zu simulieren, wird der SS7-Simulator 303 erneut aktiviert und verarbeitet die in der dritten Übergabedatei 306 gespeicherten Ereignisfolgen, wobei die Ergebnisse in der vierten Übergabedatei 307 abgelegt werden. Bei Bedarf wird nun erneut der Verkehrs-Simulator 301 aktiviert und der Zyklus SS7-Simulator, SCP-Simulator, SS7-Simulator erneut durchlaufen, um Rückkopplungen zwischen den Netzkomponenten zu simulieren. Die Iteration wird so lange durchgeführt, bis die Änderungen der Verkehrsdaten in einer oder mehrerer der Übergabedateien 304 bis 307 (bzw. oben 203, 204) ein für den Benutzer akzeptables Maß unterschritten haben und somit das System einen eingeschwungenen Zustand erreicht hat.
Statistikdaten bezüghch der einzelnen Simulationsmodule 301, 302, 303 werden in Ausgabedateien 309, 308 bzw. 310 geschrieben. Bezüghch der SS7- Simulation sind dies beispielsweise Auslastung der SRP -Prozessoren oder die Anzahl der belegten Verbindungen von SRP zum SCP bzw. zu den SSPs.
Die in den Übergabedateien hinterlegten Daten sind anrufspezifische Datensätze, die jeweils mindestens eine Zeitmarke enthalten. Diese Zeitmarke ergibt sich aus der aktuellen Simulationszeit beim Erzeugen bzw. Abarbeiten der dazugehörigen Nachricht in den entsprechenden Simulationsmodulen. Durch Differenzbildung lassen sich somit die Bearbeitungszeiten in den jeweiligen simulierten Netzkomponenten berechnen.
Figur 4 zeigt die Struktur eines erfindungsgemäßen, im Datei- sowie im Online-Modus betreibbaren Simulators. Der Simulator weist die bereits in Figur 3 dargestellten und beschriebenen Simulationsmodule Verkehrs- Simulator 401, SS7-Simulator 403 und SCP-Simulator 402 auf. Diese kommunizieren wie oben dargestellt, über Übergabedateien 406, 407, 408, 409. 20
Gegenüber dem Simulator aus Figur 3 enthält der hier dargestellte Simulator zusätzhch ein Modul zur Simulation der Überlastabwehr 404. Dieses reguhert die vom Verkehrs-Simulator 401 generierten bzw. weitergegebenen Ereignisfolgen in Abhängigkeit bestimmter benutzerdefinierter Parameter, gespeichert in Datei 424, sowie von der Belastung der übrigen Simulationsmodule.
Die Simulationsmodule 401, 402, 403, 404 sind durch ein gemeinsames Organisationsprogramm, den Online-Simulator 405, verknüpft. Es ist weiterhin eine Benutzeroberfläche 410 vorhanden, die mit allen Komponenten, also den Simulationsmodulen in direkter uni- oder bidirektionaler Verbindung steht. Außerdem bestehen zwischen Benutzeroberfläche und den Simulationsmodulen indirekte Verbindungen über Dateien 411 bis 414 (Eingabedateien für Verkehrs-Simulator 401), 415 (SS7-Eingabedatei), 416 und 423 (SCP- Ein-/Ausgabedatei), 417 bis 420
(Ausgabedateien des Online-Simulators 405), über welche sowohl die Module konfiguriert als auch ermittelte Systemdaten ausgelesen werden können. Die gestrichelten Pfeile in Figur 4 symbolisieren, wie auch in den Figuren 2 und 3, Dateioperationen, während die durchgezogenen Pfeile eine direkte Kommunikation beschreiben, z.B. durch Verknüpfung über ein gemeinsames Organisationsprogramm. Ein Pfeil beginnt bei derjenigen Komponente, die Parameter oder Nachrichten an einen anderen Simulationsteil übergibt.
Der in Figur 4 dargestellte Simulator erlaubt sowohl den Datei-Betrieb mit sequentiellem Aufrufen der einzelnen Simulationsmodule als auch den
Online-Betrieb, bei welchem die Simulationsmodule quasiparallel arbeiten.
Die Benutzeroberfläche steht jeweils mit dem Verkehrs- SS7- und. SCP- Simulator in Verbindung; die jeweilige Simulation wird von der Benutzeroberfläche unter Übergabe der entsprechenden
Simulationsparameter gestartet. Im Dateimodus laufen Teilsysteme nach ihrem Aufruf als eigenständige Programme unabhängig von der Oberfläche und ohne Interaktionen ab.
Die bidirektionale Verbindung zwischen Benutzeroberfläche 410 und Online- Simulator 405 erlaubt einerseits den Simulationsstart mit entsprechender Parameterübergabe und andererseits eine Rückgabe von "Meßdaten" zur grafischen Ausgabe während der Laufzeit (Online-Modus). Weiterhin ist es 21 dem Benutzer möghch, den Simulationsablauf vorübergehend zu unterbrechen oder vorzeitig zu beenden.
Die Simulationsmodule 401, 402, 403 und 404 sind programmiertechnisch in den Online-Simulator 405 integriert, der den quasiparallelen Ablauf der Teilsimulationen durch das Versenden und Empfangen von Nachrichten, die im globalen Ereigniskalender verwaltet werden, steuert. Im Online-Betrieb finden somit sämtliche Kommunikationsvorgänge zwischen den Modulen Verkehrs-Simulator 401, SS7-Simulator 403 und SCP-Simulator 402 über den Online-Simulator 405 statt. Die Übergabedateien 406 bis 409 werden im
Online-Betrieb nicht direkt verwendet. Indirekt finden sie sich jedoch in den lokalen Ereigniskalendern wieder.
Der Online-Simulator 405 veranlaßt die Eintragung von vorbestimmbaren Protokollgrößen, z.B. die oben beschriebenen Zeitmarken tl bis t4, die SCP- Auslastung, Daten zur Netzauslastung oder die Anzahl der belegten Leitungen, in Protokolldateien 417, 418, 419, 420. Die dort gespeicherten Daten sind in bekannter Weise an der Benutzeroberfläche ausgebbar und visualisierbar.
Da die Überlastabwehr den in das IN gelangenden Verkehr durch Rückkopplungen reguhert, ist eine Simulation von
Überlastabwehrmechanismen in den meisten Fällen nur im Online-Modus sinnvoll durchzuführen. Das Überlastabwehrmodul 404 weist daher beim in Figur 4 dargestellten Simulator keine direkte Verbindung zum SCP-Simulator 402 auf, anhand dessen Belastung der Überlastabwehr-Simulator 404 die Zahl der vom Verkehrs-Simulator 401 generierten Ereignisse reguhert. Eine Verbindung zwischen SCP-Simulator 402 und Überlastabwehr-Simulator 404 besteht lediglich im Online-Modus indirekt über dem Online-Simulator 405.
Figur 5 zeigt den prinzipiellen Ablauf einer IN-Simulation aus dem Blickwinkel des Benutzers. Die Simulationsmodule selbst sind dabei nicht dargestellt, sondern werden im Rahmen der Blackbox 501 abgearbeitet. Dabei kann der Überlastabwehr-Simulator 502 und oder der SS7-Simulator 503 jeweils ein- oder ausgeschaltet werden, in der Figur 5 durch Schalter symbolisiert. Weiterhin kann der Benutzer zwischen Datei- und Online-Modus wählen, ebenfalls symbolisiert durch einen Schalter. 22
Neben diesen, die Struktur des Simulators betreffenden Einstellungen, hat der Benutzer nach dem Start des Simulators die Möghchkeit, die tatsächlichen Simulationsparameter, also die zu simulierende Netzkonfiguration, das Verkehrsaufkommen etc. zu definieren. Bei einem Urstart werden sämtliche Eingabedateien von den Simulationsmodulen neu eingelesen. Darüber hinaus ist jedoch eine gezielte Veränderung einzelnen Parameter zur Generierung einer neuen Simulation oder auch ein erneutes Durchlaufen einer alten Simulation möglich. Der Simulator 501 ermittelt dann aufgrund der zuvor bestimmten oder aufgerufenen Simulationsparameter die vorbestimmten Ausgangsdaten, z.B. Verkehr, CPU- Auslastung, Warteschlangenlänge als Funktion der Simulationszeit, und schreibt diese in Dateien. Die Daten können nun auf dem Büdschirm dargesteHt werden oder, auf Datenträgern abgespeichert, einer weiteren Verarbeitung zugeführt werden.
Figur 6 zeigt ein Beispiel für Konfigurationsparameter des Verkehrs- Simulators sowie beispielhaft numerische Werte für diese. Die in der Tabelle der Figur 6 dargestellten Parameter lassen sich untergliedern in dienstespezifische Parameter, die für sämtliche zu simulierenden Dienste separat einsteUbar sind, Televotum-Parameter, die sich auf den Dienst
Televotum beziehen, sowie allgemeine Parameter, die für sämtliche Dienste, also für alle vom Verkehrs-Generator erzeugten Anrufe, gültig sind. Die dienstespezifischen Parameter sind für folgende IN-Dienste einstellbar: Freephone (FPH), Tele-Info-Service (TIS), UniverseUe Rufnummer (UNU), den In-Dienst FPHL und Televotum (TVS). Für den Dienst Televotum sind nicht alle der für die übrigen Dienste einstellbaren Parameters sinnvoll; diese sind daher in der entsprechenden Spalte mit einem X markiert. Weiterhin kann auch Telefonnormalverkehr (NVK) berücksichtigt werden, da auch nicht IN-spezifische Anrufe bei bestimmten Netzkonfigurationen den SSP belasten und damit zur Auslastung des IN beitragen können. Für den NVK ist ledighch die Angabe des ersten dienstespezifischen Parameters, mittlere Gesprächsdauer, sinnvoll, da die übrigen Parameter die IN-Funktionen wie Schalten eines Anrufes auf eine Ansage, oder Umlenken eines Anrufes betreffen.
Die dienstespezifischen Parameter sind die mittlere Gesrpächsdauer, mittlere Ansagendauer, maximale Ansagendauer, der Anzahl der Ansageplätze, wie Ansage und Umlenkwahrscheinhchkeit, sowie für die Wahrscheinhchkeit der 23 Umlenkung durch "Teilnehmer besetzt". Diese Parameter werden benötigt, um zu jedem Simulationszeitpunkt die Wahrscheinhchkeit für die Generierung eines Folgeereignisses zu bestimmen, also die Wahrscheinhchkeit für die Generierung eines Ereignisses EVENT oder EVENT(CALL END).
Die Televotum-Parameter sind für jeden Televotum-Dienstteilnehmer TV1, TV2 usw. separat angebbar. In dem hier gezeigten Beispiel sind ledighch zwei Dienstteilnehmer aktiv. Die einstellbaren Parameter sind: Ziel wert SSPl bzw. SSP2, Anzahl Zielwerte bis Verbindung, Startzeit, Endzeit, sowie Endzeit für Folgeanrufe. Der Parameter "Zielwert" gibt dabei die Anzahl der Televotum- Anrufe an, die beim angegebenen SSP eingehen müssen, damit eine Nachricht zum SCP generiert wird. Ist dieser Parameter auf den Wert 1 gesetzt, so handelt es sich um die Option Televotum ohne Vorzählen, ist der Wert größer als 1, so handelt es sich um Televotum mit Vorzählen im SSP. Der folgende Parameter "Anzahl Zielwerte bis Verbindung" gibt an, ob und beim wievielten Anruf eine Verbindung zum Dienstteilnehmer aufgebaut wird. Da der Dienst Televotum in der Regel in engen zeitlichen Grenzen angeboten wird, sind zu dem die Angaben der Start- bzw. Endzeit des Dienstes vorgesehen. Der Parameter "Endzeit für Folgeanrufe" gibt an, bis zu welchem Zeitpunkt verspätet eingehende TV- Anrufe noch auf eine informative, ggf. diensteteilnehmerspezifische Ansage gelenkt werden. Die Televotum- Parameter geben an, unter welchen Voraussetzungen ein vom Verkehrs- Generator zunächst generierter TV- Anruf ein IN-Erstereignis hervorruft.
Weiterhin sind folgende allgemeine Konfigurationsparameter einstellbar: Der Parameter "Zeit bis Timeout" gibt an, nach welcher Zeit nach Senden einer IN-Nachricht an den SCP und ohne Erhalt einer Antwort vom SCP ein Anruf durch den SSP abgewiesen wird. Der Parameter "Zeitverzug für Umlenkung" gibt die Verzögerung bei einem Anruf-Rerouting an. Die
Parameter "mittlere und maximale Ansagendauer "TV nicht aktiv"" sowie "Anzahl Ansageplätze" für diese Ansage geben an, wie ein außerhalb der Zeiten, in denen der Dienst Televotum aktiv ist, ankommender TV-Anruf behandelt wird. Die Parameter "Anzahl Leitungen von bzw. zu den SSPs" betreffen die Konfiguration des Netzes im Bereich zwischen
Vermittlungsstelle und SSP. Weiterhin ist die Anzahl der Leitungen für den Dienst Freephone vorgebbar. Der Parameter "mittlere Wartezeit des A- Teilnehmers" gibt an, nach welchem mittleren ZeitintervaU der anrufende 24 Teilnehmer auflegt, wenn bis dahin noch kein Verbindungsaufbau erfolgt ist. Die folgenden zwei Parameter geben an, mit welcher Wahrscheinhchkeit bei nicht erfolgreichem Verbindungsaufbau ein Folgeanruf folgt sowie mit welcher maximalen Anzahl Folgeanrufe generiert werden.
Um ein IN-spezifisches kombiniertes Verkehrsaufkommen zu generieren, sind neben den oben dargesteUten Parametern, die hauptsächlich die Generierung von IN-Folgeereignissen (EVENT) betreffen, weitere Parameter nötig, die die Randbedingungen für die Generierung von entsprechenden IN- Erstereignissen (PROVTDE INSTRUCTION) festlegen. Es ist daher die Eingabe des mittleren Verkehrsaufkommens in Anzahl der Anrufe pro Zeiteinheit vorgesehen. Das mittlere Verkehrsaufkommen ändert sich zu behebigen benutzerdefinierbaren Zeitpunkten und bleibt dazwischen konstant. Damit können behebig geformte zeithche Belastungskurven erzeugt werden, insbesondere auch solche Spitzen, wie sie bei sinngemäßer Dienstzuordnung für den Diensttelevotum typisch sind. Das mittlere Verkehrsaufkommen wird für jeden IN-Dienst (FPH, TIS, UNU, FPHL, TVl, ..., TVn) und den regulären Telefon verkehr (NVK) eingegeben. Falls mehrere SSPs vorhanden sind, wird das Verkehrsaufkommen dienstespezifisch für jeden SSP separat eingegeben. Die Anzahl der SSP ist damit auch ein Parameter, welcher im Rahmen der Verkehrs-Simulation einstellbar ist.
Beim Verkehrsaufkommen wird von einem stufenförmigen zeithchen Verlauf ausgegangen, wobei jede Stufe bzw. jedes Zeitintervall vorzugsweise die gleiche zeithche Länge hat. Die Anzahl der Intervalle sowie die Intervaüänge ist dabei vorgebbar.
Nach den Regeln der Verkehrstheorie wird aufgrund der obenstehenden Angaben für jeden Simulationszeitpunkt bzw. für jedes Simulationszeitintervall die Wahrscheinhchkeit ermittelt, daß ein Anruf mit einer speziellen Dienste- bzw. Diensteteilnehmerkennung an einem SSP ankommt. Die Länge der Simulationszeitintervalle hegt dabei vorzugsweise wesenthch unterhalb der Länge der IntervaUe, für die ein mittleres Verkehrsaufkommen von Benutzer vorgegeben wurde. Die Länge der Simulationsintervalle hegt vorzugsweise im Bereich Nanosekunden, während sich das Verkehrsaufkommen auf der Zeitskala von Sekunden, z.B. 10-100 s, ändert. Die Länge des Simulationszeitintervalls ist vorzugsweise so zu 25 wählen, daß maximal ein Anruf pro Intervall erzeugt wird und sich somit sämtliche erzeugte Anrufe in chronologischer Folge auflisten lassen.
Die jeweilige momentane Wahrscheinhchkeit wird unter Annahme einer gegebenen Wahrscheinhchkeitsverteüung sowie der vorgegebenen momentanen Durchschnitts- Verkehrsmenge für den behandelten Dienst, Diensteteilnehmer bzw. SSP berechnet. Die verwendete Wahrscheinhchkeitsverteüung ist vorzugsweise eine Poisson-Verteüung, da diese das statistische Eintreffen voneinander unabhängiger Ereignisse beschreibt und somit die statistischen Fluktuationen des Telefonverkehrs am besten wiedergibt. Für jeden Dienst, Diensteteilnehmer und/oder SSP wird somit eine zeithche Folge von Ereignissen erzeugt, wobei die Anzahl der Anrufe pro Zeiteinheit statistisch um den zuvor vorgegebenen momentanen Mittelwert schwankt. Bei den Diensten FPH, TIS, UNU, FPHL sowie Televotum ohne Vorzählung wird potentieU jeder generierte Anruf zu einem IN-spezifischen Ereignis, welches zur Auslastung des Intelligenten Netzes beiträgt, und daher zur Simulation der Performance des IN, insbesondere des SCP, relevant ist.
Die so generierten Erstereignisse, den IN-Nachrichten PROVTDE
INSTRUCTION entsprechend, werden mit ihrer Erzeugungszeit tl in chronologischer Folge in die erste Übergabedatei in den globalen Ereigniskalender bzw. im Datei-Modus eingetragen. Televotum -Anrufe führen bei aktivierter Vorzählung nur bei jedem n-ten Anruf zu einem IN- Erstereignis (PROVTDE INSTRUCTION). Dieses wird ebenfaUs mit der
Erzeugungszeit tl in den globalen Ereigniskalender bzw. in die Übergabedatei aufgenommen. Die übrigen Anrufe sowie Anrufe des regulären Telefonverkehrs belasten ledighch den SSP, führen aber nicht zur Erzeugung von IN-Ereignissen.
Weiterhin erzeugt der Verkehrs- Generator einem IN -Anruf bzw. Erstereignis zugeordnete Folgeereignisse unter Berücksichtigung der in der Konfigurationsdatei eingegebenen Wahrschei li chkeiten , die das weitere Schicksal eines IN-Ereignisses betreffen. Kommt z.B. die IN-Verbindung zu einem realen Teilnehmer bzw. die Schaltung auf einen Ansageplatz aufgrund der Verbindungsbehandlungsinformationen (CREATE-JOIN) vom SCP in der Simulation ordnungsgemäß zustande, so wird das Gespräch nach der angegebenen mittleren Gesprächs- bzw. Ansagendauer beendet, indem der 26
Verkehrsgenerator das Folgeereignis EVENT(CALL END) erzeugt und in die Übergabedatei bzw. in den globalen Ereigniskalender einträgt. Kommt die IN- Verbindung mit dem vom SCP mitgeteüten realen Teilnehmer in der Simulation nicht zustande, was vom Verkehrs -Generator unter Berücksichtigung der dafür angegebenen Wahrscheinlichkeiten ermittelt wird, erzeugt der Verkehrs-Generator als Folgeereignis die IN-Nachricht EVENT, mit welcher beispielsweise eine Rerouting-Information vom SCP angefordert wird. Auf diese Weise ist der Verkehrsgenerator imstande, IN- typische Ereignisfolgen zu erzeugen, die realen Verkehrsaufkommen im IN weitgehend entsprechen.
Zu jedem IN -Ereignis werden folgende Parameter gespeichert: Die Identifikationsnummer des Anrufs, der Zeitpunkt tl, zu dem die Nachricht vom SSP gesendet wird, die Identifikationsnummer der Nachricht, z.B. 1 für PROVTDE INSTRUCTION, 2 für EVENT, 3 für EVENT(CALL
END), die Identifikationsnummer des Dienstes, z.B. 3 für TIS, 5 für UNU, 6 für FPH, 10+j (J=0, ..., 89) für den j-ten Dienstteilnehmer des Dienstes TV sowie eine Identifikationsnummer des SSP.
Weiterhin wird zur Berücksichtigung der Global Title Translation im IN in einer vorteilhaften Ausgestaltung der Erfindung auch eine Kennziffer zum Global Title (GT) als Routing-Kriterium generiert und als Parameter des IN- Ereignisses gespeichert. Die GT-Klasse wird ebenfaUs über eine vorgegebene Wahrscheinhchkeitsverteüung generiert. Im STP/SRP-Simulator werden dann vorzugsweise GT-spezifische Prozeßketten angestoßen, welche die Routingfunktionahtäten der STP/SRP-Ebene, also beispielsweise die Vermittlung des Rufs an das Netz eines anderen Netzanbieters, simulieren.
Weiterhin ist die Zuordnung der vom Verkehrssimulator generierten Ereignisse zu Nutz- und Lastklassen vorteilhaft. Anrufbezogene IN-Ereignisse sind einer Nutzklasse zugeordnet, während beispielsweise Management- Verkehr zwischen den IN-Ebenen durch Ereignisse einer Lastklasse simuliert werden kann. Zu jedem vom Verkehrssimulator generierten Ereignis wird eine entsprechende Klassenkennziffer erzeugt und gespeichert, die von den übrigen Simulationsmodulen erkannt wird und ggf. die Weiterverarbeitung des Ereignisses mitbestimmt. 27 Im Online-Modus werden die Folgeereignisse vom Verkehrsgenerator während des Simulationsbetriebs mit den gegebenen Wahrscheinlichkeiten erzeugt, nachdem das dazugehörige Erstereignis die Simulations-Module SCP- Simulator sowie ggf. SS7-Simulator durchlaufen hat, nachdem also ein der SCP-Nachricht CREATE-JOIN entsprechendes Ereignis vom SCP-Simulator erzeugt und, ggf. nach Durchlaufen des SS7-Simulators beim Verkehrssimulator zur Abarbeitung anliegt. Im Online-Betrieb werden somit Rückkopplungen zwischen den Simulationsmodulen automatisch bei der Generierung IN-spezifischer Ereignisfolgen durch den Verkehrs-Simulator berücksichtigt.
Im Dateimodus können derartige Rückkopplungen wegen des sequentieUen Aufrufs der Simulationsmodule nur durch Iteration erreicht werden. Beim ersten Aufruf des Verkehrs-Simulators werden daher die Erstereignisse in oben beschriebener Weise generiert, und für die Folgeereignisse wird zunächst eine vorgegebene, beispielsweise zeitlich konstante SCP -Antwortzeit angenommen. Diese Antwortzeit wird beim erneuten Aufruf des Verkehrs- Simulators durch die Antwortzeiten korrigiert, die sich aus der vom SCP- Simulator bzw. SS7-Simulator an den Verkehrs-Simulator übergebenen Übergabedatei ergeben. Bei mehrmahgem Durchlaufen des Simulators ergibt sich ein eingeschwungener Zustand, bei dem auch Wechselwirkungen zwischen den Modulen weitestgehend berücksichtigt sind.
Im Online-Betrieb erfolgt die Generierung der IN-spezifischen Erstereignisse während des Ablaufs der Gesamtsimulation, also zu jedem
Simulationszeitpunkt, z.B. in ns-Abständen. Dadurch kann auch ein Eingreifen der Überlastabwehr bei momentaner Überlast der übrigen Simulationsmodule simuliert werden und ein Anruf vor der Erzeugung bzw. Weitergabe eines entsprechenden IN-Ereignisses abgewiesen werden.
Eine Folge der am SSP bzw. an den SSPs ankommenden Anrufe, die in der Regel ein IN-Ereignis nach sich ziehen, kann jedoch vor Simulationsbeginn nach den oben geschüderten verkehrstheoretischen Verfahren erzeugt und während der Simulation abgearbeitet werden, d.h. als IN-Ereignis weitergegeben oder aufgrund der Überlastabwehr faUengelassen werden.
Aus dem generierten Verkehrsaufkommen kann für jeden Simulationszeitpunkt die Auslastung der Zeichenkanäle im Intelligenten Netz 28 ermittelt werden. Aufgrund der benutzerdefinierten Wahrscheinlichkeiten zum weiteren Schicksal des Anrufs (z.B. Gespräch oder Ansage bestimmter mittlerer Dauer) kann auch die Anzahl der belegten Sprechverbindungen zu und von den SSPs und/oder die Anzahl der belegten Abnehmerleitungen für Teilnehmer am Dienst Freephone als Funktion der Zeit protokolliert und ausgegeben werden. Weiterhin ist als Funktion der Simulationszeit ausgebbar, wieviele Anrufe in verschiedenen Stadien abgewiesen wurden, z.B. unmittelbar nach Erzeugung durch Überlastab ehr, nach Ablauf des Timeouts bei Nichtreaktion des SCP oder wegen Belegung sämtlicher Ansageplätze.
Figur 7 zeigt den prinzipieUen Simulationsablauf im Dateimodus. Nach dem Start des Simulators werden die Eingabedateien der einzelnen Simulationsmodule eingelesen. Der Verkehrs-Simulator steUt fest, ob bereits eine Datei mit Nachrichten vom SCP vorhanden ist (Übergabedatei 204 aus Figur 2 bzw. 307 aus Figur 3). FaUs ja, werden diese Daten bezüghch der SCP-Antwortzeiten analysiert und bei der Generierung der Ereignisfolgen durch den Verkehrs-Simulator berücksichtigt. Falls nein, wird ohne Analyse zum nächsten Schritt übergegangen und für die SCP-Antwortzeiten ein Default- Wert verwendet. Die Initiahsierung der Zähler beinhaltet das Setzen einer internen Simulationsuhr auf den Zeitpunkt Null und das Initialisieren der Zustandsvariablen und statistischen Zähler mit Anfangswerten.
Im folgenden Schritt wird ein Startereignis generiert, also eine erste Nachricht PROVTDE INSTRUCTION, und in den Ereigniskalender eingetragen. Der Ereigniskalender enthält während der Simulation aUe noch abzuarbeitenden Ereignisse, geordnet nach ihrem Startzeitpunkt.
Nach der Initiahsierung beginnt innerhalb einer Schleife die eigenthche Simulation. Es folgt zunächst die Abfrage der Abbruchbedingung, wobei die Simulation dann abgebrochen wird, wenn die aktueüe Simulationszeit t größer als eine vorgegebene Simulationsdauer ist. Innerhalb der Schleife wird zunächst das nächste Ereignis aus dem Kalender ausgetragen und die Simulationsuhr auf den Zeitpunkt des folgenden Ereignisses weitergeschaltet. Beim Start der Simulation ist dieses nächste Ereignis das nach der Simulation erzeugte erste Ereignis. Der Ereignistyp des abzuarbeitenden Ereignisses wird bestimmt und darauffolgend die dazugehörige Ereignisroutine abgearbeitet. 29
In diesem Beispiel sind neun verschiedene Ereignistypen vorgesehen. Von links nach rechts sind dies das Eintreffen eines neuen Anrufs (NEWCALL), das Eintreffen eines wiederholten Anrufsversuchs (FOCALL, der Erhalt der Nachricht CREATE-JOIN vom SCP (CONNECTSSPCON), Verbindungsaufbau zum B-Teilnehmer (CONNECT B), Anrufumleitung (REROUT), der Erhalt der Nachricht CREATE-JOIN vom SCP bei Anrufumleitung (REROUTCON), Gesprächsende (TALKEND), Ende einer Ansage (TAPEND) sowie die Abweisung eines Anrufs (REJECT).
Bei dem ersten im Kalender eingetragenen Ereignis handelt es sich in der Regel um einen neuen Anruf (NEWCALL). Die dem zugeordnete Ereignisroutine veranlaßt den Verkehrs-Generator zur Generierung des nächsten Anrufs sowie zur Simulation des Verbindungsaufbaus zum SSP. Die Ereignisroutine NEWCALL simuliert das Senden einer IN-Nachricht
PROVTDE INSTRUCTION vom SSP an den SCP durch Generierung eines entsprechenden Ereignisses und Eintragung in den Ereigniskalender bzw. in die Übergabedatei.
Der SCP sendet daraufhin die Nachricht CREATE-JOIN an den SSP; in der Simulation wird daher der Erhalt des CREATE-JOIN vom SCP als Ereignis zum Zeitpunkt aktueüe Simulationszeit plus SCP -Antwortzeit in den Ereigniskalender eingetragen. Damit ist die erste Ereignisroutine beendet, die Simulationsuhr wird zum nächsten Ereigniszeitpunkt vorgesteüt, dieses Ereignis aus dem Kalender gelesen und bearbeitet, falls nicht die Simulationszeit schon abgelaufen ist. Die Zeitdauer zwischen zwei Ereignissen wird übersprungen.
Angenommen, das nächste Ereignis ist der Erhalt der Nachricht CREATE- JOIN vom SCP. Dann wird die Fortsetzung des Verbindungsaufbaus vom SSP mit der Ereignisroutine (CONNECTSSPCON) simuliert. Dabei wird beispielsweise mit den oben geschüderten Wahrscheinlichkeiten ermittelt, ob ein Verbindungsaufbau zum B-Teilnehmer gelingt (Folgeereignis CONNECTB), wobei der B-Teilnehmer ein realer Teilnehmer oder eine Ansage sein kann, oder ob ein Ruf nach zuvor erfolglos versuchter
Weitervermittlung umgeleitet werden muß '(Folgeereignisse (CONNECTB oder REROUT). Beim Aufruf des Ereignisses CONNECTB wird die Verbindung zum B-Teilnehmer aufgebaut. Die Folgeereignisse sind Talk-End 30 bzw. Tape-End, deren Zeitpunkte sich aus dem mittleren Anruf bzw. Ansagendauer sowie der aktueUen Simulationszeit ergeben. Mißlingt der Verbindungsaufbau, wird mit gewisser Wahrscheinlichkeit ein Folgeanruf erzeugt und das Ereignis FOCALL in den Ereigniskalender eingetragen. Der wiederholte Anruf ersuch wird im folgenden wie ein erster Anrufsversuch behandelt.
Die Schleife Aufruf eines Ereignisses aus dem Ereigniskalender, Durchlaufen der entsprechenden Ereignisroutine, ggf. Erzeugen eines Folgeereignisses und Eintragung desselben in den Ereigniskalender, Setzen der Simulationszeit auf den Zeitpunkt des nächsten, im Ereigniskalender eingetragenen Ereignisses, sowie Aufruf desselben wird solange durchlaufen, bis die zuvor eingesteUte Simulationszeit errreicht ist, bzw. bis ein Ereignis auftritt, welches das Ende der Simulation kennzeichnet. Nach Simulationsende stehen die im Ereigniskalender oder in ProtokoUdateien eingetragenen, vom Simulator erzeugten und abgearbeiteten Daten zur Auswertung der Performance des Intelligenten Netzes bzw. einzelner Komponenten zur Verfügung.
Figur 8 zeigt den prinzipieüen Simulationsablauf im Online-Modus. Zunächst wird die Konfiguration vom Benutzer bestimmt, wobei die entsprechenden
Konfigurationsdateien von den Simulationsmodulen eingelesen werden. Im in Figur 8 gezeigten Beispiel sind der Verkehrs-, SS7-, SCP-, sowie Überlastabwehr- (ACG- Simulator) aktiv und werden durch das gemeinsame Organisationsprogramm, den Online-Simulator, verwaltet. Wie in den Ausführungen zu Figur 7 beschrieben, wird zunächst durch den Verkehrs- Simulator ein Startereignis erzeugt. Die globale Simulationsuhr wird auf t=0 gesetzt. Innerhalb einer Schleife werden nun wie beim in Figur 7 dargesteUten Simulationsablauf die in den globalen Ereigniskalender eingetragenen Ereignisse in chronologischer Reihenfolge aufgerufen, die dazugehörenden Ereignisroutinen abgearbeitet und gegebenenfaUs erzeugte Folgeereignisse in den globalen Kalender eingetragen. Jeweils nach Beendigung einer Ereignisroutine wird die Simulationszeit auf den Zeitpunkt des nächsten Ereignisses vorgesteüt und dieses bearbeitet. Als Abbruchbedingung für die Schleife dient wiederum eine vorbestimmte maximale Simiüationszeit, die bei jedem Schleifendurchlauf mit der aktueUen Simulationszeit verghchen wird. Wenn das Simulationsende erreicht ist, werden die Teüsimulationen durch Freigabe des dynamischen Speichers beendet. Ist das Simulationsende nicht erreicht, wird der 31 Gemeinschaftsspeicher, auf den die Benutzeroberfläche während der Simulation zugreift, aktualisiert, so daß die aktueUen Systemdaten dem Benutzer unmittelbar angezeigt werden können. Weiterhin werden die Systemdaten für die Überlastabwehr- Simulation aktualisiert. Schließlich werden in konstanten Zeitabständen die ermittelten Meßdaten, also SCP- Auslastung, Warteschlangenlänge usw., protokolliert und in die entsprechenden ProtokoUdateien eingetragen und/oder dem Benutzer visualisiert. Anschließend folgt die Abarbeitung des nächsten im Kalender vorhandenen Ereignisses.
Bei dem hier dargesteUten Beispiel werden insgesamt 13 globale Ereignistypen unterschieden, die sich in zwei Gruppen unterteüen lassen:
Interne Ereignisse: Bei den internen Ereignissen handelt es sich um Routinen, die den Zustand nur eines einzelnen Simulationsmoduls beeinflussen. Jedes Simulationsmodul ist dabei ein eigenständiges ereignisorientiertes Programm mit einer Vielzahl von Ereignissen und einem eigenen lokalen Kalender zu deren Verwaltung. Aus der Sicht der Ablaufsteuerung des Gesamtsimulators existieren in diesem Beispiel drei globale interne Ereignisse TRAFIC INTERN, SS7 INTERN und SCP INTERN, die jeweüs Verweise auf die lokalen Ereignisskalender darsteUen.
Figur 9 zeigt dazu schematisch die Abarbeitung eines solchen internen Ereignisses aus der Sicht der Online-Simulation. Beim Aufruf der jeweiligen Teilkomponente wird in Abhängigkeit vom internen Programmablauf das nächste interne und gegebenenfaUs das nächste externe Ereignis erzeugt und in den lokalen Kalender des Simulationsmoduls eingetragen. Zusätzhch werden aüe benötigten Parameter des Ereignisses an die Ablaufsteuerung übergeben, um in den globalen Kalender der Gesamtsimulation einsortiert zu werden.
Die übrigen Ereignisse des in Figur 8 dargesteUten Simulationsablaufs sind externe Ereignisse, die zur Kommunikation zwischen den Simulationsmodulen dienen. Sie entsprechen den in einem realen intelligenten Netz von einer Komponente zu einer anderen gesendeten
Nachrichten, z.B. PROVIDE INSTRUCTION, CREATE-JOIN, EVENT. Die hier auftretenden externen Ereignisse sind: PROINST TO SS7, EVENT TO SS7 und SSP CALLEND TO SS7, die den Nachrichten PROVIDE 32 INSTRUCTION, EVENT bzw. EVENT(CALL END) des SSP an den SCP entsprechen. Die genannten internen Ereignisse werden vom Verkehrs- Simulator erzeugt (Routine: TRAFFIC INTERN) und finden ihre Entsprechung im Datei- Modus in den Ereignissen, die in der ersten Übergabedatei 304 (Figur 3) eingetragen sind.
Die externen Ereignisse PROVTNST TO SCP, EVENT TO SCP und CALL END TO SCP stehen für die Nachrichten PROVIDE INSTRUCTION, EVENT bzw. EVENT(CALL END), die vom SS7-Systems bzw. vom SRP/STP an den SCP übergeben werden. Diese Ereignisse entprechen damit den in der zweiten Übergabedatei 305 (Figur 3) eingetragenen Ereignissen.
Die Antwort des SCP besteht in den Ereignissen SCP CALL END TO SS7 sowie CREATE-JOIN TO SS7. Ersteres Ereignis bestätigt die Verbindungsauslösung, das zweite simuliert die Übermittlung von
Verbindungsaufbauinformationen. Diese Ereignisse entsprechen den in der dritten Übergabedatei 306 eingetragenen Ereignissen. Sie werden vom SCP- Simulator erzeugt und richten sich an den SS7-Simulator. Die externen Ereignisse CALL END TO SSP sowie CREATE-JOIN TO SSP werden vom SS7-Simulator erzeugt und stehen für die Weitervermittlung einer Nachricht vom SCP an einen SSP durch das SS7- System. Die entsprechenden Ereignisse werden im Datei-Modus in der vierten Übergabedatei 307 gespeichert.
Die Nachricht CALL END TO SSP wird nur im FaUe eines inaktiven SS7 benötigt.
Die Abarbeitung eines externen Ereignisses innerhalb der Ablaufsteuerung besteht in der Eingabe der entsprechenden Nachricht in eine der Simulationskomponenten. Dabei ist es möghch, daß die Komponente durch die Nachricht zur Erzeugung eines neuen internen Ereignisses veranlaßt wird, welches dann an die Online-Simulation weiter- gegeben und in den globalen Kalender eingetragen wird. Nach Abarbeitung einer Ereignisroutine wird das nächste Ereignis aus dem globalen Kalender ausgetragen und die Simulationsuhr aktualisiert, d.h. auf den Startzeitpunkt dieses Folgeereignisses gesetzt. 33 Bei Abarbeitung des internen Ereignisses TRAFFIC INTERN wird der Verkehrssimulator aufgerufen und erzeugt einen neuen Ruf. Aufgrund der aktueUen Belastung der übrigen Simulationsmodule wird entschieden, ob dieser neue Ruf durch die Überlastabwehr (ACG) abgewiesen wird. Falls der Anruf durch die Überlastabwehr abgewiesen wurde, wird diese Tatsache protokolliert, und die Ereignisroutine ist beendet. FaUs der neue Ruf nicht abgewiesen wurde, wird er in die Simulation aufgenommen, d.h. das entsprechende Ereignis PROVINST TO SS7 in den globalen Ereigniskalender eingetragen. In eine ProtokoUdatei wird für den generierten Anruf ein neues Element eingefügt, wobei folgende Daten gespeichert werden: Die
Identifikationsnummer des jeweiligen Rufes, welche bei seiner Generierung vom Verkehrssimulator erzeugt wird, die Dienste-Identifikationsnummern des Rufes, die Nummer des SSP an dem der Ruf ankommt, die Nachrichtenidentifikationsnummer, d.h. ob die Nachricht PROVTDE INSTRUCTION oder EVENT vorhegt, sowie der Zeitpunkt tl, zu dem für den aktueUen Ruf die entsprechende Nachricht PROVIDE INSTRUCTION oder EVENT generiert wurde. Im Laufe der Simulation wird diese Protokollzeüe durch weitere Zeitmarken ergänzt, und zwar nach Abarbeiten der Routine PROVINST TO SCP oder EVENT TO SCP durch den SS7-Simulator (Zeitmarke t2), nach Abarbeiten der Routine CREATE-JOIN SS7 durch den SCP-Simulator (Zeitmarke t3) sowie nach Abarbeiten der Routine CREATE- JOIN TO SSP durch den SS7- Simulator (Zeitmarke t4).
Nachrichten vom Typ CALL END werden bei der Protokollierung nicht berücksichtigt, weü die durch sie verursachten Verzögerungszeiten nicht zur Wartezeit eines IN -Anrufers beitragen und daher die Aussage über die Antwortzeiten verfälschen würden. Bei einer veränderten FragesteUung kann hingegen auch die Protokollierung entsprechender Zeitmarken sinnvoU sein.
Die zweite und dritte Zeitkomponente enthält nur dann gültige Werte, wenn der SS7-Simulator während der Simulation aktiv war.
Da ein vollständiger Datensatz zu einem einzelnen Ruf erst zu dem Zeitpunkt vorhegt, zu dem die Nachricht CREATE-JOIN am SSP angekommen ist, müssen die Daten zunächst zwischengespeichert werden. Bei der Generierung eines Anrufes wird ein neuer Datensatz angelegt, der während des weiteren Programmablaufs um die noch fehlende Zeitkomponenten ergänzt wird. Durch 34 die Büdung von Differenzen zwischen den einzelnen, zu einem Anruf gehörenden Zeitmarken können folgende Antwortzeiten ermittelt werden: t2 - tl: Verzögerung einer Nachricht im SS 7 auf dem Weg zum SCP; t3 - 12: Verzögerung einer Nachricht im SCP; t4 - 13: Verzögerung einer Nachricht im SS7 auf dem Weg zum SCP; t4 - tl: Gesamte Verzögerung einer Nachricht im IN.
Die Netzauslastung wird während des Simulationsablaufes in konstanten ZeitintervaUen gespeichert. Es werden keine rufspezifischen Informationen, sondern globale statistische Netzdaten gespeichert. Dabei werden vorzugsweise folgende Größen protokolliert: Die Zeit der aktueUen Messung, die Anzahl der in das IN gelangenden Anrufe pro Sekunde, der Anteü der Nachrichten, die sich zur Zeit in Bearbeitung im SS7 auf dem Weg zum SCP befinden, die Anzahl der Nachrichten im SCP sowie die Anzahl der Nachrichten im SS 7 auf dem Weg zum SSP.
Innerhalb des SCP- Simulators werden für jeden Prozessor die Auslastung, die Warteschlangenlänge und die Anzahl der bearbeiteten Nachrichten (Dispatches) ermittelt und in einer ProtokoUdatei gepeichert. Der Online- Simulator greift auf diese Daten zu und schreibt die über aüe CPUs ermittelten Werte in eine Datei. Die Daten können während der Online- Simulation durch die Benutzeroberfläche dargesteUt werden.
Schließlich werden anhand der Verkehrsdaten die Anzahl der belegten Leitungen von bzw. zu den SSPs ermittelt und als Funktion der Simulationszeit protokolliert.
Figur 8.a zeigt zur Ergänzung von Figur 8 den Zusammenhang zwischen den verwendeten Ereignissen. Der Simulator aus Figur 8 wurde um ein separates Modul zur Simulation des SRP ergänzt, das auch Teü des SS7-Simulators sein kann, weshalb hier auch Ereignisse vom Typ SRP_INTERN auftreten. Die vier internen Ereignisse TRAFFIC NTERN, SS7JNTERN, SRP NTERN und SCP_INTERN veranlassn den Aufruf eines Simulationsmoduls zwecks Bearbeitung eines Ereignisses. AUe weiteren externen Ereignisse dienen dem Übergang von einem Simulationsmodul zum nächsten. Das Startereignis bei der Gesamtsimulation ist immer ein Ereignis TRAFFIC_INTERN, da der Verkehrssimulator die QueUe der IN-Anrufe ist. 35 Jedes Simulationsmodul kann nach der Abarbeitung eines internen Ereignisses ein Folgeereignis zur Bearbeitung durch dasselbe Simulationsmodul generieren. Gleichzeitig kann eines der durch einen abgehenden Pfeü gekennzeichneten externen Ereignisse erzeugt werden. Diese Information erhält der Online-Simulator vom jeweiligen Simulationsmodul.
Der Aufruf eines externen Ereignisses entspricht dem Senden einer Nachricht zu dem jeweiligen anderem Knoten des IN. Beim Senden einer Nachricht unterscheidet macn drei Nachrichten. Diese finden sich in jeweüs drei verschiedenen Übergängen vom Verkehrsgenerator bis zum SCP-Simulator wieder. Es wird ein TRAFFIC_INTERN-Ereignis aufgerufen, das diese Nachricht generiert und innerhalb der Simulation eine eindeutige Nummer (CaUID) für diesen Anruf vergibt. Darauf folgt entsprechend der Nachricht ein PROINST-TO-SS7-, EVENT-TO-SS7- oder SSP-CALLEND-TO-SS7-Ereignis und ein weiteres TRAFFIC_INTERN-Ereignis, faUs noch mehr Verkehr generiert werden soU. Das externe Ereignis wird dann bearbeitet und hat ein SS7-INTERN-Ereignis zur Folge. Dieses generiert sich mehrmals hintereinander, bis die Bearbeitung im SS7-Teü des SSP beendet ist und ein externes Ereignis zum SRP generiert wird. Die Nachricht ändert sich dabei nicht, d.h. ein eingehendes PROVIDE-INSTRUCTION wird auch als solches weitergegeben. Auf dieses externe Ereignis folgen dann analog zum SS 7- INTERN-Ereignis mehrere SRP-INTERN-Ereignisse. Die Übergabe an das SCP-INTERN-Ereignis geschieht dann analog zur Übergabe des SS 7- INTERN-Ereignisses an das SRP-INTERN-Ereignis.
Nach mehrmahgem Bearbeiten eines SCP-INTERN-Ereignisses beauftragt der SCP-Simulator den Online-Simulator, eine Nachricht zum SSP-Simulator zu schicken. Hierzu gibt es zwei verschiedene Nachrichten CREATE-JOIN und CALLEND , die analog zum bereits beschriebenen Szenario bis zum SS 7- Simulator weitergeleitet werden und zu einem SS7-INTERN-Ereignis führen. AUerdings führen von dort nur Ereignisse vom Typ CREATE-JOIN zu einem TRAFFIC-INTERN-Ereignis; Ereignisse vom Typ CALLEND veranlassen den Verkehrsgenerator nicht zur Erzeugung von dazugehörigen Folgeereignissen. Es können aüerdings Folgeanrufe konfiguriert werden, die nach einer vom Zufaüsgenerator zu bestimmenden Zeit vom Verkehrssimulator gestartet werden, wenn keine Verbindung aufgebaut werden konnte. Diese haben die gleiche CaUID wie der ursprüngliche Anruf. 36
Beim Aufruf des Verkehrssimulators durch ein TRAFFIC -INTERN-Ereignis als Folge eines CREATE-JOIN-Ereignisses wird per ZufaUsgenerator gemäß den vorbestimmten Wahrscheinlichkeiten festgelegt, wann die nächste Nachricht zu diesem Ereignis abgesendet wird. Zu diesem Zeitpunkt wird dann die oben beschriebene Ereigniskette gestartet.
Bei mehr als einem Anruf wird für jeden Anruf diese Ereigniskette beibehalten. Die Ereignisse mehrerer sich überschneidender Anrufe werden abhängig von ihrer SteUung im globalen Ereigniskalender behandelt.
Im folgenden soü auf die Struktur des SCP- und des SS 7- Simulators eingegangen werden.
Figur 10 zeigt dazu schematisch das Prinzip der SCP-Simulation. Es handelt sich wiederum um eine ereignisgesteuerte Simulation, wobei nur diskrete Ereigniszeitpunkte betrachtet werden und zu jedem Ereigniszeitpunkt Zustandsänderungen auftreten können.
Der SCP-Simulator weist einen lokalen Ereigniskalender auf, in welchem sämtliche vom SCP-Simulator zu bearbeitenden Ereignisse in chronologischer Reihenfolge eingetragen sind. Es werden folgende Ereignisse unterschieden: Nachrichten: Nachrichten repräsentieren Anfragen des SSP bzw. SS7 an den SCP zur Anrufbehandlung, wobei die Ankunft einer Nachricht im SCP bzw. im SCP-Simulator ein Dienstbearbeitungsprogramm, bestehend aus einer vorbestimmbaren Prozeßfolge, startet. Eine Nachricht entspricht einem globalen externen Ereignis.
(Lokales) Internes Ereignis: Ein lokales internes Ereignis führt zur Beendigung eines Prozesses bzw. Ereignisses und Generierung eines neuen Prozesses bzw. entsprechenden Ereignisses, wobei sich dessen Art und Eigenschaften aus der im Dienstbearbeitungsprogramm definierten Prozeßkette ergeben.
(Lokales) Externes Ereignis: Ein lokales externes Ereignis wird erzeugt, wenn ein Dienstbearbeitungsprogramm beendet wurde, also nach .Abarbeiten des letzten, in der Prozeßkette spezifizierten Prozesses. Ein externes Ereignis führt zum Senden einer Nachricht zum SSP bzw. zum SS7 und damit zur Generierung eines globalen externen Ereignisses und dessen Eintrag in den globalen Ereigniskalenders. 37
Figur 11 zeigt ein Beispiel für Konfigurationsparameter des SCP- Simulators. Der obere Teü der TabeUe enthält eine Auflistung sämtlicher zu simulierender Prozesse, die vom SCP durchführbar sind und am Verbindungsaufbau bzw. - abbau beteiligt sind. Die Einzelprozesse sind durch eine Prozeß- Identfikationsnummer (ProzeßlD) gekennzeichnet; die Angabe des Prozeßnamens dient ledighch zur einfacheren Anpassung der Konfiguration an die Funktion eines realen SCP. Jedem Prozeß ist eine Prozeßdauer, die hier in Millisekunden angegeben ist, sowie eine Priorität zugeordnet. Die Angaben sind benutzerdefinierbar, so daß sich beispielsweise die
Auswirkungen einer veränderten Prioritätszuordnung oder einer veränderten Prozeßdauer mit dem Simulator ermitteln lassen.
Im unteren Teü der TabeUe ist benutzerdefinierbar der SCP-Dienstablauf angegeben. Jedem Dienst, hier gekennzeichnet durch die Dienste- Identifikationsnummer, und dienstspezifisch jeder Nachricht PROVIDE INSTRUCTION, EVENT oder EVENT(CALL END), gekennzeichnet durch die Nachrichten-Identifikationsnummer ist eine Prozeßfolge zugeordnet. Die Prozeßfolge bzw. das Dienstbearbeitungsprogramm ist dabei durch aufeinanderfolgende Angaben der ProzeßlDs der oben aufgehsteten Prozesse definiert. Weiterhin wird hier jede Nachricht dienstspezifisch einer CPU zugeordnet, auf welcher die Prozeßfolge abgearbeitet wird. Es können auch sämtliche Nachrichten auf sämtlichen verfügbaren CPUs abgearbeitet werden.
Es ist weiterhin möghch, einen Einzelprozeß in behebig viele Teüprozesse zu zerlegen, zwischen denen in der Prozeßfolge andere Prozesse stehen können. Belegt der erste Teüprozeß in einer Prozeßfolge die zur ProzeßlD gehörende Kopie, so bleibt diese so lange belegt, bis der letzte Teüprozeß voUständig abgearbeitet wurde. Eine solche Charakteristik besitzen aUe Serviceprozesse.
Um einen Cache- oder Festplattenzugriff oder das Inkrementieren eines Zählers für den TV-Dienst zu simulieren, können Warteprozesse mit in die Prozeßfolge eingefügt werden. Die mittlere Wartezeit und deren Varianz ist dabei einzusteUen; die tatsächhche wird während der Simulation aufgrund eine gegebenen Wahrscheinhchkeitsverteüung mit diesen Parametern, z.B. Gauß-Verteüung, daraus ermittelt. 38 Weiterhin ist, wie in Fig. 11 gezeigt, als Parameter die Verzögerung des Front End Systems ST2000, das bei manchen Netztopologien die SchnittsteUe zwischen dem SCP sowie dem SS7-System büdet, sowie der maximale Zählerstand für den Dienst Televotum angebbar.
Figur 12 zeigt ein der SCP-Simulation zugrunde hegendes ModeU der Prozeßverwaltung einer CPU 1201 innerhalb eines SCP. PrinzipieU kann jedoch jedes ModeU einer solchen Prozeßverwaltung in den SCP-Simulator durch entsprechende Definition der Warteschlangen bzw. Ereigniskalender übernommen werden. Die Prozeßverwaltung bestimmt ledighch die Anzahl und Art der Verknüpfung der SCP-Warteschlangen bzw. der lokalen Ereigniskalender innerhalb des SCP -Simulators und damit, wie eine Nachricht bzw. die sich daraus ergebenden Einzelprozesse innerhalb des Simulators abgearbeitet werden. Der Simulator ist dabei in weiten Grenzen an Benutzerangaben anpaßbar, so daß behebige Realitäten simuliert werden können. Es ist keine bestimmte Hard- und/oder Softwarestruktur vorgegeben, sondern behebige Konfigurationen können modelliert werden.
Die CPU 1201 ist im in Fig. 12 gezeigten FaU mittels zweier Local area Networks (LAN) 1202, 1203 an das SS7 angeschlossen, beispielsweise mit Hilfe zweier Token-Bus-LAN über das Front End System ST2000.
Bei SCP ankommende Nachrichten 1208 (PROVIDE INSTRUCTION) werden in Abhängigkeit vom jeweiligen Dienst in dienstespezifische Warteschlangen 1204, 1205, 1206, 1207 geschrieben. In dieser Warteschlange wartet ein
Prozeß bzw. eine Nachricht auf externe/interne Nachrichten, die den Prozeß zur Bearbeitung aufrufen. Erhält ein Prozeß die gewünschte Nachricht, so reiht er sich in die Warteschlange der aktivierten Prozesse ein. In dieser Prioritätswarteschlange 1210 sind die aktivierten Prozesse nach Prioritäten geordnet, während die in die dienstespezifischen Warteschlangen 1204 bis 1207 eingetragenen Ereignisse chronologisch geordnet sind. Der Prozeß mit der höchsten Priorität innerhalb der Prioritätswarteschlange 1210 erhält die CPU und wird dort bearbeitet. FaUs beispielsweise ein Prozeß nicht von der CPU bearbeitet werden kann, weü aUe Inkarnationen des aufzurufenden Prozesses belegt sind, wird dieser nicht lauffähige Prozeß in einer zusätzlichen Warteschlange 1209 verwaltet, bis eine Prozeßinkarnation wieder bereitsteht und der Prozeß in den lauffähigen Zustand übergeht; dann wird er in die Prioritätswarteschlange 1210 eingetragen. 39
Figur 13 zeigt ein weiteres ModeU der Prozeßverwaltung einer CPU zur Simulation der SCP-Funktionen. An einer CPU 1301 ankommende Nachrichten werden gemäß dem Dienstebearbeitungsprogramm in eine Prozeßfolge umgewandelt. Der erste dieser Prozesse wird in eine prozeßspezifische Warteschlange 1302, 1303, 1304, 1305 eingetragen, um von der zugeordneten Prozeßroutine 1307, 1308, 1309, 1310 bearbeitet zu werden. In den prozeßspezifischen Warteschlangen 1302 bis 1305 sind die ankommenden Prozesse in chronologischer Folge eingeordnet. Jeder Prozeßroutine 1307, 1308, 1309, 1310 ist weiterhin eine bestimmte Priorität Pl bis Pn zugeordnet. Es sind auch Konfigurationen denkbar, in denen die Warteschlangen 1302, 1303, 1304, 1305 ledighch prioritätsspezifisch sind, d.h. aUe, auch unterschiedhche Prozesse eine bestimmten Priorität aufnehmen, die dann in chronologischer Reihenfolge abgearbeitet werden.
Die Prozeßroutinen können für den selben Prozeß in mehreren Inkarnationen vorhanden sein, beispielsweise jeweüs eine Kopie pro Dienst. In diesem FaU sind die prozeßspezifische Warteschlangen 1302 bis 1305 auch dienstespezifisch. Ist eine Prozeßroutine 1307 bis 1310 bereit, wird der nächste Prozeß aus der entsprechenden Warteschlange 1302 bis 1305 aufgerufen; der Prozeß ist dann bereit. Ist zudem die CPU 1301 frei, wird der Prozeß bearbeitet. Nach Abarbeitung eines Prozesses wird durch die CPU 1301 der in der Prozeßkette auf den abgearbeiteten Prozeß folgende Prozeß erzeugt und in die entsprechende Warteschlange eingetragen. Nicht lauffähige Prozesse werden in einer zusätzlichen Warteschlange 1306 verwaltet, bis sie wieder in den lauffähigen Zustand übergehen. Unterbrochene, aber lauffähige Prozesse werden an den Anfang ihrer Warteschlange gesteht und werden als nächstes bearbeitet, wenn es deren Priorität zuläßt.
Unterbrochen werden laufende Prozesse beispielsweise durch Prozesse bzw. Ereignisse, die das Betriebssystem der CPU simulieren soUen. Solchen Ereignissen wird in der Simulation höhere Priorität gegeben als den dienstbearbeitenden Prozessen. BenutzereinsteUbar ist, welche Zeit die CPU im Mittel auf die Bearbeitung solcher Prozesse verwenden muß. Ein derartiger Prozeß selbst wird dann durch einen ZufaUsgenerator erzeugt. 40 Figur 14 zeigt ein schematisches objektorientiertes ModeU eines SCP- Simulators. Der Simulator weist eine Mehrzahl von Untereinheiten auf, die jeweüs die Funktion einer CPU 1401, 1402, 1403, 1404 simulieren. Diese Untereinheiten sind modular zum SCP-Simulator zusammensetzbar.
Eine ankommende Nachricht wird vom Front End System ST2000, Bezugsziffer 1405, empfangen und je nach vorbestimmten CPU- Auswahlkriterien einer CPU 1401 bis 1404 zur voüständigen Bearbeitung weitergegeben. Das Front End System 1405 wird dabei mit einer konstanten Verzögerungszeit simuhert. Es kann innerhalb des SCP-Simulators auch eine eigene Warteschlange aufweisen.
Ein Folgeereignis, also z.B. die Nachricht EVENT oder EVENT(CALL END) wird automatisch auf der CPU bearbeitet, auf welcher schon das Erstereignis behandelt wurde, da in der Realität nur dort der Kontext zum Anruf gespeichert ist. Die Zuweisung eines Erstereignisses (PROVIDE INSTRUCTION) zu einer CPU kann jedoch nach verschiedenen Kriterien erfolgen: Zum einen können Statistikdaten des SCP-Simulators herangezogen werden, z.B. die Auslastung der jeweiligen CPU, die Anzahl der Nachrichten zur Bearbeitung in der CPU zusammen mit dem momentanen Zustand der CPU (aktiv oder inaktiv), die Summe der verbleibenden Wartezeiten aUer auf der CPU laufenden bzw. wartenden Prozesse. Dies erfordert jedoch Rechenzeit während der laufdenden Simulation zur Ermittlung der Statistikdaten und dementsprechender Entscheidungsfindung. Alternativ ist daher die selbständige Nachrichtenaufhahme durch die CPUs vorgesehen: Sämthche Erstereignisse (entsprechend den Nachrichten PROVIDE INSTRUCTION) werden in eine aUen CPUs gemeinsame Warteschlange geschrieben; die Folgeereignisse (entsprechend den Nachrichten EVENT oder EVENT(CALL END)) werden in CPU-spezifische, ggfs. auch CPU- und nachrichtenspezifische Warteschlangen eingetragen. FaUs der Prozessor einer CPU frei ist, kann automatisch die nächste Nachricht aus einer CPU- spezifischen oder aus der gemeinsamen Warteschlange gelesen werden.
Das Ereignis durchläuft bei der Bearbeitung innerhalb der CPU-Simulation eine festgelegte Prozeßfolge, z.B. wie in Fig. 11 gezeigt. Jeder Prozeß der Prozeßfolge kann auch in eine Mehrzahl von Teüprozessen zerfaUen, wobei zwischen den Teüprozessen andere Prozesse ablaufen können. Für jeden Prozeß existiert auf der CPU wenigstens eine Prozeßroutine 1408, 1409, 1413 41 .s 1416, mit welcher die in die Prozeßwarteschlange 1410, 1411 eingetragenen Prozesse bearbeitet werden, wenn sie an der Reihe sind. Eine Prozeßroutine kann auch in mehreren Inkarnationen auf der CPU vorhanden sein, wobei beispielsweise die Zuordnung eines Ereignisses zu einer der Prozeßroutinen dienstespezifisch erfolgt. Dies ist in Figur 14 symbolisiert durch zwei Blöcke von Prozeßroutinen 1408, 1409, 1413 bzw. 1414 bis 1416 mit jeweüs einer Prozeßwarteschlange 1410 bzw. 1411.
Ein ankommendes Ereignis wird wie folgt verarbeitet: Das Ereignis wird zunächst in die Prozeßwarteschlange 1410 bzw. 1411 eingetragen und wartet darauf, daß die entsprechende Prozeßroutine des aufzurufenden Prozesses frei wird. Ist der Prozeß bereit, wird das Ereignis in die Prioritäts warteschlange eingereiht. Die in die Prioritätswarteschlange 1407 eingetragenen Ereignisse werden von der CPU 1401 der Reihe nach abgearbeitet. Während der Abarbeitung eines Prozesses durch die CPU können Warteereignisse auftreten, die z.B. Zugriffe auf die Festplatte simulieren. Diese Warteereignisse werden zufällig oder auch prozeßbedingt erzeugt und in einer Warteschlange 1412 eingetragen. Diese Ereignisse haben höhere Priorität und unterbrechen einen auf der CPU 1401 laufenden Prozeß.
Während der Abarbeitung eines Prozesses können diensteabhängig Zählereignisse verlangt werden, die durch einen Zähler 1406 erzeugt werden. In diesem Zähler 1406 können von aüen CPUs Anfragen eintreffen und sich gegenseitig blockieren. Dies führt zu einer Verlängerung der Prozeßverarbeitungszeiten, obwohl die aufrufende CPU dadurch nicht belastet wird.
Die CPU- Auslastung wird vom SCP-Simulator zur Gewinnung von SCP- Statistikdaten wie folgt ermittelt: Zu jedem vom Benutzer angegebenen Zeitpunkt, z.B. aUe n Simulationssekunden, wird berechnet, wieviel Prozent der Zeit innerhalb des zurückhegenden, benutzerdefinierten ZeitintervaUs Δt die CPU aktiv war, d.h. aUe Zeiten der innerhalb des letzten ZeitintervaUs Δt gelaufenen Einzelprozesse werden addiert und ihr prozentualer Anteü am ZeitintervaU Δt berechnet.
Die Warteschlangenlänge als weiteres Kriterium zur SCP-Belastung ergibt sich unmittelbar aus der Länge der jeweiligen Warteschlangen bzw. lokalen Ereigniskalender . 42
Figur 15 zeigt die .Anordnung der SS7-Schichten, die am Dialog zwischen SSP und SCP beteiligt sind und daher mit dem SS7-Simulator simuhert werden. Die oberste Schicht 1501 steüt die Schicht der SS7-Benutzer dar, repräsentiert also die Anbindung des SSP bzw. SCP an das SS7. Von hier werden Nachrichten in das Intelligente Netz bzw. das SS 7 gesendet bzw. empfangen. Darunter hegen in folgender Reihenfolge die TCAP-Schicht 1502, die SCCP-Schicht 1503 sowie die MTP-Schichten 1504 (Level 3 bis 1), die jeweüs mit eigenen Prozessoren bestimmte SS7-Funktionahtäten realisieren. Der Nachrichtenfluß vom SSP zum SCP erfolgt in der im rechten
Zeichnungsteü skizzierten Weise von Schicht 1501 bis 1504 und zurück zu 1501, wobei der Nachrichtenfluß bidirektional ist.
Zur Simulation des SS7 werden die SS7-Ebenen 1502 bis 1504, also TCAP, SCCP, MTP 1-3, getrennt modelliert. Hierbei werden die einzelnen Prozesse einer Ebene durch Verzögerungszeiten nachgebüdet. Um den Fluß der Zeichengabenachrichten innerhalb einer Ebene bzw. zwischen zwei Ebenen simulieren zu können, wird ein WarteschlangenmodeU benutzt.
Als Beispiel ist dazu in Figur 16 die ModeUierung der MTP3-Ebene 1008 des SRP innerhalb des SS7-Simulators dargesteUt. Die drei in dieser Ebene auftretenden Prozesse sind MESSAGE DISTRIBUTION (HMDT), MESSAGE DISCRIMINATION (HMDC) und MESSAGE ROUTING (HMRT). Das Verhalten der Prozesse untereinander und mit den angrenzenden Schichten SCCP 1607 bzw. MTP2 1609 ist in Figur 16a als Flußdiagramm sowie in Figur 16b als Flußdiagramm mit lokalen Prozeß warteschlangen 1601, 1602, 1603 dargesteUt.
Der Prozeß HMDC 1604 erhält Zeichengabenachrichten von der Ebene MTP2 und verteüt diese abhängig vom Zielknoten der Nachrichten. Vor der
Bearbeitung durch den Prozeß HMDC 1604 werden die Nachrichten in die dazugehörige Prozeßwarteschlange 1603 eingeordnet. Für den eigenen Knoten, also für den SRP, der der MTP-Schicht 1608 zugeordnet ist, bestimmte Nachrichten werden an den Prozeß HMDT 1605 weitergeleitet. Sie werden in die entsprechende Prozeßwarteschlange 1601 einsortiert und nach Abarbeitung durch den Prozeß HMDT an den SCCP 1007 übergeben. Ist eine Nachricht für einen anderen Knoten bestimmt, wird sie vom Prozeß HMDC 1604 an den Prozeß HMRT 1606 geleitet. Dieser gibt die Nachricht nach 43 Abarbeitung, also nach Aufruf aus der entsprechenden Prozeßwarteschlange 1602, an die Ebene MTP 2 1609 weiter. Gleiches gut für Nachrichten, die die Ebene MTP3 1608 vom SCCP 1607 erhält.
Die in Figur 16b verwendeten FIFO-Warteschlangen 1601, 1602, 1603 sind in der Lage, mehrere Zeichengabenachrichten aufzunehmen und nacheinander abzuarbeiten. Die Reihenfolge der Abarbeitung ist durch die jeweilige Verzögerungszeit bestimmt und wird in den lokalen Ereigniskalender des SRP bzw. SS7-Simulator eingetragen.
Figur 17 zeigt als weiteres Beispiel die Modellierung der TCAP-Schicht des SS7. Gemäß der DarsteUung in Figur 15 ist die TCAP-Schicht 1702 zwischen der Schicht der SS7-USER 1701 und der SCCP-Schicht 1703 angeordnet. Die Nachrichtenflüsse zwischen den Schichten sowie innerhalb der TCAP-Schicht 1702 sind durch Pfeüe angedeutet. In der TCAP-Schicht 1702 werden in diesem Beispiel vier Prozesse simuhert, die Prozesse INVOCATION STATE MACHINE 1704, COMPONENT COORDINATOR 1705, DIALOG HANDLING 1706 sowie TRANSACTION SUB-LAYER 1707. Jedem dieser Prozesse ist eine Prozeß warteschlange 1708 bis 1711 zugeordnet. Nach Abarbeitung eines in eine der Warteschlangen eingetragenen Ereignisses wird entsprechend dem hier dargesteUten Nachrichtenfluß ein Folgeprozeß derselben Schicht aufgerufen oder die Nachricht an die darüber- oder darunterliegende SS7-Schicht weitergeleitet. Die Prozeßfolgen sind dabei benutzerdefinierbar und dem realen Prozeßablauf innerhalb einer TCAP- Schicht flexibel anpaßbar.
Figur 18 zeigt ein Beispiel für Konfigurationsparameter des SS7-Simulators. Es sind zunächst für die einzelnen SS7-Schichten die Prozeßzeiten für die an der Kommunikation zwischen SSP und SCP beteiligten Prozesse angebbar. Dabei werden in diesem Beispiel ledighch die Prozeßzeiten der TCAP- und
SCCP-Prozessoren auf Seiten des SSP und des SCP sowie der Prozessoren auf der MTP3-Ebene im Bereich von SSP, STP und SCP angegeben. Es sind jeweüs drei oder vier Prozesse pro Ebene beteiligt. Die Prozeßabfolge in den SS7-Schichten ist wie bei der SCP-Simulation das Dienstebearbeitungsprogramm vom Benutzer festlegbar und kann somit flexibel den realen Gegebenheiten angepaßt werden. Den einzelnen Prozessen kann auch jeweüs eine bestimmte Priorität zugewiesen werden, was hier nicht dargesteUt ist. 44
Im unteren Teü der in Figur 18 gezeigten TabeUe sind die benutzerdefinierbare Parameter angegeben, welche die Topologie des Intelligenten Netzes im Bereich des SS 7 betreffen, z.B. die Anzahl der SCPs, die Anzahl der Zeichenkanäle zwischen SSP und STP sowie zwischen STP und SCP, die laufzeitbedingte Verzögerung einer Nachricht zwischen STP und SSP bzw. SCP sowie die Verzögerung zwischen den Prozessoren. Weiterhin ist die Nachrichtenlänge angebbar.
Figur 19 zeigt die Implementierung des Überlastabwehr-Simulators 1903 in den IN-Simulator im Online-Betrieb sowie dessen prinzipieUe Funktionsweise. Der Überlastabwehr-Simulator 1903 reguhert in diesem Beispiel die vom Verkehrssimulator 1902 generierte bzw. weitergegebene Verkehrsmenge aufgrund von Systemdaten, die eine Aussage über die momentane Lastsituation, insbesondere des SCP-Simulators, zulassen, vom Online-Simulator 1901 verwaltet und dem Überlastabwehr-Simulator 1903 über die Online-SchnittsteUe übergeben werden.
Im hier gezeigten Beispiel reguliert der Überlastabwehr-Simulator 1903 die vom Verkehrssimulator 1902 generierte bzw. weitergegebene Verkehrsmenge nach dem Prinzip des Automatic CaU Gapping (ACG): Innerhalb eines ZeitintervaUs Δtl (gap time) wird beispielsweise jeweüs nur ein Anruf, ggfs. mit vorbestimmten Eigenschaften, vom SSP zum SCP durchgelassen. Das ZeitintervaU Δt2 (gap duration) gibt dabei an, wie lange eine solche Reduzierungsmaßnahme andauert. Auch der Überlastabwehrmechanismus nach dem Prinzip des "Leaky Bücket" kann mit dem Überlastabwehr- Simulator 1903 nachgebüdet werden.
Der Überlastabwehr-Simulator 1903 (Overload Prozeß) wird vom Verkehrssimulator 1902 aufgerufen. Dabei übergibt er einen Anruf mit den entsprechenden Parametern, wie z.B. Dienste-, Nachrichten-, SSP- Identi.fi kationsnummer , Zeit. Neben diesen Daten erhält der Overload Prozeß die aktueUen Systemdaten, wie z.B. CPU-Auslastung, Antwortzeiten und Warteschlangenlänge, vom Online-Simulator 1901. Der einmal initialisierte Overload Prozeß steuert sich mit Hilfe der eigenen Zähler und der übergebenen Systemdaten. Für jeden SSP, Dienst und/oder Diensteklasse kann ein eigener Zähler vorhanden sein. Nachdem der Anruf in dem entsprechenden Zähler erfaßt wurde, berechnet der Überlastabwehr- 45 Simulator den aktueUen Überlastlevel mit Hilfe der Systemdaten. Anschließend werden die Gap-Parameter für den aktueUen Überlastlevel aus der InitiahsierungstabeUe ausgelesen. Die InitialisierungstabeUe ist in der Initiahsierungsdatei abgelegt, die beim Start des Überlastabwehr-Simulator 1903 aufgerufen wird. Die Gap-Parameter sind beispielsweise das ZeitintervaU Δtl (gap time), innerhalb welchem nur jeweüs ein Anruf, ggfs. mit bestimmten Eigenschaften, vom SSP zum SCP durchgelassen wird, sowie das ZeitintervaU Δt2 (gap duration), das angibt, wie lange eine solche Reduzierungsmaßnahme andauert.
Für die Berechnung des aktueUen Überlastlevels werden innerhalb eines vorbestimmbaren Zeitfensters aUe Anrufe gezählt und gegebenenfaUs zeitlich gewichtet. Die Wichtung hängt vorzugsweise exponentieU vom Alter des Anrufs ab, wobei ein jüngerer Anruf stärker gewichtet wird als ein länger zurückhegender. Es erfolgt weiterhin eine Aufteüung der Last auf die SSPs bzw. auf die Dienste, um auch dienste- und/oder SSP-abhängige Überlastabwehr simulieren zu können, bei welcher selektiv Anrufe mit bestimmten Eigenschaften unterdrückt werden.
Es sind verschiedene Überlastlevel vom Benutzer definierbar, denen benutzerdefinierte Gap-Parameter zugeordnet sind.
Nach der Berechnung des Überlastlevels werden die Gap-Maßnahmen entsprechend aktualisiert, z.B. die Länge der ZeitintervaUe Δtl bzw. Δt2 angepaßt. Es wird dann geprüft, ob der aktueüe Anruf einer solchen
Maßnahme unterhegt oder nicht. Dem aufzurufenden Prozeß wird dann im ErfolgsfaU der Rückgabewert TRUE oder eine andere Kennzeichnung übergeben, ansonsten der Wert FALSE bzw. eine andere, dem zugeordnete Kennzeichnung.
Der Rückgabewert wird vom Verkehrssimulator 1902 ausgewertet. Im FALSE-FaU wird miteiner voreingesteUten Wahrscheinhchkeit ein Folgeanruf generiert. Im TRUE-FaU wird der Anruf vom Verkehrssimulator 1902 an die Online-SchnittsteUe weitergereicht, von dort wird der Anruf dem SCP- oder SS7-Simulator übergeben. Der Verkehrssimulator erzeugt daraufhin einen neuen Anruf, und der Prozeß beginnt von neuem. 46 Figur 20 zeigt die Implementierung des Überlastabwehr-Simulators 2002 in den IN-Simulator im Datei-Betrieb. Im Datei-Betrieb werden die Anrufe zuvor mit dem Verkehrssimulator generiert und in einer Übergabedatei 2001 abgelegt. Da im Dateibetrieb keine aktueUen Systemdaten an den Überlastabwehr-Simulator 2002 übergeben werden können, mißt er selbst die aktueU anhegende Last in Form von Anrufen pro Zeiteinheit. Die aktueüe Last wird mit einem vorbestimmten Wert für die maximale Anzahl vom Verkehrssimulator ausgehender Anrufe verglichen; dieser ist beispielsweise in der Initiahsierungsdatei gespeichert. Aus aktueüer eingehender Last und maximaler ausgehender Last wird der aktueüe Überlastlevel berechnet.
Analog zum Online-Betrieb werden anschließend die neuen Abwehrparameter aus der InitiahsierungstabeUe ausgelesen und die Abwehrmaßnahmen aktualisiert.
Figur 21 zeigt ein Beispiel für mit dem IN-Simulator ermittelte
Simulationsdaten. Es wurde dabei die Konfiguration zugrunde gelegt, die sich nach den Figuren 6, 11 und 18 aus den dort dargesteUten Konfigurationsdateien ergibt. Der SS7-Simulator ist aktiv, während der Überlastabwehr-Simulator abgeschaltet ist. Es wurde ein Telefonverkehr von 30 -Anrufen pro Sekunde im ZeitintervaU 0 bis 500 Sekunden vorgegeben.
Die Figuren 21.a bis c zeigen die vom Simulator ermittelten Daten zur Netzstatistik. In Figur 21.a ist der vorgewählte mittlere Telefonverkehr sowie der vom Verkehrssimulator generierte Telefon verkehr jeweüs als Funktion der Simulationszeit dargesteUt. Der eingesteUte Telefonverkehr ist gestrichelt dargesteUt und entspricht den obengenannten Vorgaben, d.h. beträgt im Intervaü 0 bis 500 Sekunden konstant 30 Anrufe pro Sekunde, danach 0 Anrufe pro Sekunde. Der generierte Telefonverkehr, dargesteUt als durchgezogene Linie zeigt statistische Schwankungen um den vorgewählten Mittelwert. Er fäüt etwas nach dem Zeitpunkt t = 500 s auf Null ab.
Figur 21.b zeigt die SCP-Antwortzeit in Sekunden als Funktion der Simulationszeit. Bei dem konstanten Telefonverkehr von ca. 30 Anrufen pro Sekunde steht sich gemäß diesem Simulationsergebnis ein eingeschwungener Zustand ein, d.h., der SCP arbeitet die an ihn gesteUten Anfragen mit einer Antwortzeit von 0,4 bis 0,7 Sekunden ab. 47 Figur 21.c zeigt die Anzahl der Nachrichten, die sich zur Abarbeitung im SCP- Simulator befinden, als Funktion der Simulationszeit. Erwartungsgemäß sind die Anzahl der Anrufe im SCP und die Antwortzeit des SCP stark miteinander korreliert.
Die Figuren 2 l.d-f zeigen SCP-Statistikdaten als Funktion der Zeit, und zwar die Auslastung der CPUs in %, die Anzahl der Nachrichten in einer CPU- Warteschlange sowie die Anzahl von einer CPU bearbeiteten Prozesse pro Zeiteinheit. Es ist jeweüs die maximale, minimale und mittlere CPU- Auslastung, Warteschlangenlänge und Anzahl der Dispatches dargesteUt. Die Anzahl der Nachrichten, die sich zu einer bestimmten Zeit im SCP in Bearbeitung befinden, schwankt gemäß Figur 21. c im Mittel zwischen 20 und 60, während sich in der Warteschlange, Figur 21.e, nur durchschnittlich 6 Nachrichten befinden. Auf diesen Werten, sowie auch aus der mittleren CPU- Auslastung von 80 % läßt sich erkennen, daß der SCP bei der gewählten Konfiguration ein Verkehrsaufkommen von 30 Anrufen pro Sekunde ohne Probleme verkraftet.
Figuren 21.g-i, zeigen SS7-Statistikdaten. Figur 2 g entspricht 2 a und zeigt den eingesteüten bzw. generierten Telefonverkehr als Funktion der
Simulationszeit. Figur 21.h zeigt die Verzögerung einer Nachricht im SS7- Simulator auf dem Weg vom SSP zum SCP (gestrichelt) als Funktion der Zeit, sowie die Verzögerung einer Nachricht auf dem Weg vom SCP zum SSP (gepunktet). Figur 21i zeigt die Anzahl der Nachrichten im SS7 in Richtung SCP (gestrichelt) bzw. in Richtung SSP (gepunktet) als Funktion der
Simulationszeit. Die Verzögerungszeiten im Zeichengabesystem hegen weit unter denen des SCP und erreichen einen Maximalwert von 0,045 Sekunden.
Figur 2l.j zeigt die SSP-Statistikdaten als Funktion der Zeit, d.h. die Anzahl der belegten Leitungen von und zu SSP1 bzw. SSP2 (linke bzw. rechte
Kurven). Die Anzahl der belegten Leitungen von und zu den SSPs erreicht bei ungefähr 300 einen stationären Zustand. Zum Zeitpunkt T = 300 Sekunden wechselt der gesamte Telefonverkehr vom SSPl zum SSP2. Dies wurde in der Verkehrsdatei so eingesteht.
Figur 22 zeigt ein weiteres Beispiel für mit dem IN-Simulator ermittlte Simulationsdaten, hier bei einem stark wechselnden Verkehrsaufkommen. Das Verkehrsaufkommen wurde alle 100 Sekunden geändert, und zwar von 48 40 auf 20, auf 80, auf 10, auf 50 und auf 5 Anrufe pro Sekunde. Der SS7- Simulator ist aktiv, während die Überlastabwehr inaktiv ist. Die Zuordnung der Abbüdungen zu den simulierten Größen entspricht der in Figur 21.
Figur 22. a zeigt, daß der generierte Verkehr dem eingesteüten
Verkehrsaufkommen bis zum Zeitpunkt t = 250 s folgt, wobei das generierte Verkehrsaufkommen durch statistische Fluktuationen verzerrt ist. Zum Zeitpunkt t = 250 s bricht das generierte Verkehrsaufkommen, also die Anzahl der in das IN gelangenden, vom Verkehrs-Simulator erzeugten Nachrichten gegenüber den Vorgaben stark ein. Dies ist mit Hilfe der Abbüdung 22.j zu erklären. AUe in das Netz führenden Leitungen sind zur Zeit t = 250 s belegt, so daß nur noch ein geringer Teü der Anrufe zu einem IN-Ereignis fuhren kann.
Ohne den Eingriff der Überlastabwehr kommt es in der in Figur 22 dargesteUten Simulation zu starken Anstiegen der SCP -Antwortzeit, sobald die Grenze von 30 Anrufen pro Sekunde überschritten wird. Die Anzahl der Anrufe im SCP sowie die SCP-Warteschlangenlänge nimmt ebenfalls stark zu. Sobald dieser Grenzwert von 30 Anrufen pro Sekunde unterschritten wird, ist es dem SCP möghch, die wartenden Nachrichten abzuarbeiten, so daß die Verzögerungszeit und auch die Länge der Warteschlange abnimmt. Die Verarbeitungszeit der Nachrichten im zentralen Zeichengabesystem schwankt trotz der unterschiedlichen Verkehrsmengen um nur 0,02 Sekunden.
Figur 23 zeigt eine Simulation mit demselben eingesteüten Verkehrsaufkommen wie bei Figur 22, hier jedoch mit aktiviertem Überlastabwehr-Simulator. Dem Überlastabwehr-Simulator wurde ein maximales Verkehrsaufkommen von 30 Anrufen pro Sekunde vorgegeben. In Figur 23. a ist die Begrenzung des generierten Verkehrsaufkommens auf diese durchschnitthch 30 Anrufe pro Sekunde sichtbar. Die Antwortzeit des SCP, Figur 23.b wird daher auf einen Wert von etwa 0,4 bis 0,5 Sekunden gesenkt, was den im Beispiel der Figur 21 zu einem konstanten Verkehrsaufkommen von 30 Anrufen pro Sekunde ermittelten SCP-Antwortzeiten entspricht. Die Antwortszeiten sind damit um den Faktor 100 kleiner als beim Beispiel der Figur 22.
Gewerbliche Anwendbarkeit: 49
Der erfindungsgemäße IN-Simulator ist in aüen Stadien der Planung sowie des Betriebs eines InteUigenten Kommunikationsnetzwerkes ein sinnvoües Werkzeug, um die Performance des Netzes zu testen, bestimmten Vorgaben anzupassen sowie SchwachsteUen aufzuspüren. Durch die große Flexibüität der Simulationsmodule ist eine Anpassung an gegebene, aber auch an zukünftige Realitäten problemlos möghch. Durch Vergleich mit simulierten Werten und den der Simulation zugrunde hegende Parametern gelingt es, die Konfiguration des realen Intelligenten Netzes so zu wählen, daß unter den gegebenen Randbedingungen eine bestmöghche Effizienz des IN reahsiert wird. Dies führt zu erheblichen Kosteneinsparungen beim Betrieb und bei der Planung Intelligenter Netze, da mit Hilfe der EN-Simulation die optimale Konfiguration des Intelligenten Netzes und seiner Komponenten ermittelt und direkt in die Realität umgesetzt werden kann, ohne daß kostenaufwendige Experimentierzeiten am realen IN notwendig werden. Der IN-Simulator ist ein geeignetes Werkzeug zur Ermittlung von Management-Parametern, die z.B. die problematische Überlastabwehr auf eine stabüe Basis stehen können. Die Ergebnisse der Simulation ermöglichen auch die Entwicklung und Überprüfung von aUgemeinen globalen oder netzknotenbezogenen Managementfunktionen, die effektiver reahsiert und eingesetzt werden können als die bisher verwendeten Überlastabwehrmechanismen.
50
Liste der Bezugszeichen:
VermittlungssteUe 101 SSP 102 STP bzw. SRP 103
SCP-Eingangsprozessor 104 Telefon-Nutzkanäle 105 SS7-Kanäle 106,107,108 SCP 109 Verkehrs-Simulator 201,301,401, 1902 SCP-Simulator 202,302,402 SS7-Simulator 303,403,503 Übergabedateien 203,204,304,305,306,307,
406-409, 2001 SCP-Ausgabedatei 205,308,423
Verkehr- Ausgabedatei 206,309
SS 7- Ausgabedatei 310
SCP-Eingabedatei 207,311,416
Verkehr-Eingabedatei 208,209,210,211,212,
312-316, 411-414
SS7-Eingabedatei 317,415
Überlastabwehr-Simulator 404,502, 1903, 2002
Benutzeroberfläche 410
ProtokoUdateien 417-420 Dateinamen-Datei 421
Überlastabwehr-Eingabedatei 422
"Black box" 501
CPU 1201,1301,1401,1402,1403,1404
LAN (zum Anschluß an das SS 7) 1202,1203 Dienstespezifische Warteschlangen 1204,1205,1206,1207,1410,1411
IN-Nachricht/Ereignis 1208
Warteschlange für nicht lauffähige Prozesse 1209,1306
Prioritätswarteschlange (für aktivierte, lauffähige Prozesse) 1210,1407
Prozeßspezifische Warteschlange 1302,1303,1304,1305,1601,
1602,1603 51
Prozeßroutine 1307-1310, 1408, 1409,
1413-1416, 1604,1605,1606,
1704-1707
Front-End-System ST2000 1405
Zähler 1406
"Warteereignis" 1412
SS7-Userschicht 1501,1701
TCAP-Schicht 1502,1702
SCCP-Schicht 1503,1703,1607
MTP-Schicht 1504, 1505, 1506, 1608, 1609
Online-Simulator 405, 1901

Claims

52 Patentansprüche
1. Simulator zur Simulation eines InteUigenten Netzwerks (IN)- das aus wenigstens einem Service Switching Point SSP (102), an welchen Anrufe mit IN-spezifischen Rufnummern vermittelt werden, einem Service Control Point SCP (109), welcher einem SSP Informationen zur Anrufweiterbehandlung zur Verfügung steüt, sowie einem Zeichengabesystem Nr. 7 (SS 7), über welches der Dialog zwischen SSP (102) und SCP (109) stattfindet, besteht, wobei der Simulator folgende Komponenten aufweist: 1.1. Ein Modul (201, 301, 401) zur Simulation behebiger IN-typischer Ereignisfolgen (Verkehrssimulator) nach den Regeln der Verkehrtheorie; 1.2. einem Modul (202, 302, 402) zur ereignisorientierten Simulation des Service Control Point (SCP-Simulator) unter Verwendung von ProzeßmodeUen; 1.3. Mittel (203, 204, 304-307, 406-409) zur Datenübergabe zwischen den Modulen;
1.4. Mittel (207, 311, 416, 208-212, 312-317, 411-415) zur Eingabe und Speicherung der Netzkonfiguration, Kommunikationsdienstespezifikation und sonstigen Simulationsparametern sowie deren Übergabe an die entsprechenden Module;
1.5. Mittel (205-207, 308-310, 417-420, 423) zur Ausgabe und/oder Speicherung der simulierten Daten.
2. Simulator nach Anspruch 1, dadurch gekennzeichnet, daß ein Modul (303, 403, 503) zur ereignisorientierten Simulation des
Zeichengabesystems Nr. 7 (SS7-Simulator) auf der Basis von ProzeßmodeUen und/oder konstanten Verzögerungszeiten vorgesehen ist.
3. Simulator nach Anspruch 2, dadurch gekennzeichnet, daß der SS7-Simulator (303, 403, 503) die Komponenten SSP, Signal Transfer bzw. Relay Point (STP bzw. SRP) und Anbindung an den SCP durch ProzeßmodeUe simuhert sowie SS7-Zeichenkanäle zwischen SSP, STP und SCP durch eine konstante Verzögerung simuhert.
4. Simulator nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß ein Modul (404, 502) zur Simulation von Überlastabwehrmechanismen vorgesehen ist (Überlastabwehr-Simulator), welches die Anzahl der von wenigstens einem der übrigen Simulationsmodule verarbeiteten Ereignisse in 53 Abhängigkeit von der Belastung eines oder mehrerer der Simulationsmodule, z.B. in Abhängigkeit von der Warteschlangenlänge, und von benutzerdefinierbaren Parametern modifiziert;
5. Simulator nach Anspruch 4, dadurch gekennzeichnet, daß der Überlastabwehr-Simulator (404, 502) die Menge der von Verkehrssimulator (201, 301, 401) erzeugten und/oder weitergegebenen Ereignisse in Abhängigkeit von der Belastung des SCP-Simulators (202, 302, 402) steuert.
6. Simulator nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß zur AufsteUung der Netzkonfiguration und/oder Kommunikationsdienstespezifikation wenigstens einer, vorzugsweise eine Mehrzahl der folgenden Parameter durch Eingabe an einem Spezifikations- Editor, insbesondere Benutzeroberfläche (410), benutzerdefinierbar ist, wobei die Parameter in einer oder mehreren Konfigurationsdateien (207, 311, 416, 208-212, 312-317, 411-415) gespeichert werden und bei Simulationsbeginn den jeweiligen Simulationsmodulen übergeben werden: 6.1. bzgl. der SS7-Simulation: Anzahl SSPs, Anzahl STPs/SRPs, Anzahl der Zeichenkanäle zwischen STP/SRP und SCP bzw. SSP, Verzögerungen zwischen STP/SRP und SCP bzw. SSP, Art und/oder Anzahl der in verschiedenen SS7-Schichten wie MTP1, MTP2, MTP3, SCCP, TCAP eingesetzten Prozessoren, darauf ablaufende Prozesse mit Prozeßzeiten, Verzögerungen zwischen diesen Prozessoren; 6.2. bzgl. der SCP-Simulation: Art und/oder Anzahl der Prozessoren (CPUs) eines SCP, Art der Zuweisung eines Ereignisses zu einem Prozessor (z.B. dienstespezifisch), Art, Dauer und/oder Priorität im SCP laufender Prozesse, Art der Umsetzung eines IN-Ereignisses in eine SCP-Prozeßfolge, Anzahl Inkarnationen eines Prozesses pro CPU; 6.3. bzgl. der Verkehrssimulation:
6.3.1. aUgemeine Parameter: Zeit bis zum Timeout, Verzögerungszeit bei Umlenkung, Anzahl Leitungen von und/oder zu den SSPs, Folgeanruf - Wahrscheinhchkeit, maximale Anzahl Folgeanrufe, mittlere/maximale Ansagedauer, Anzahl Ansageplätze; 6.3.2. dienstespezifische Parameter: mittlere Gesprächs- und/oder Ansagendauer, maximale Ansagendauer, Anzahl Ansageplätze, Ansagewahrscheinlichkeit, Umlenk-Wahrscheinhchkeit, Anzahl Leitungen; 54 6.3.3. für den Dienst TV je Entscheidungsmöghchkeit: Startzeit, Endzeit, Endzeit für Folgeanrufe, Zielwert, Anzahl Zielwerte; 6.4. bzgl. der Überlastabwehr-Simulation: kritische SCP- Warteschlangenlänge, kritische SCP -Auslastung, Dauer der Anruf-Abwehr am SSP.
7. Simulator nach Anspruch 1 oder 6, dadurch gekennzeichnet, daß der Verkehrssimulator (201, 301, 401) IN-typische Ereignisfolgen aufgrund ganz oder teüweise benutzerdefinierbarer Angaben erzeugt, die in einer oder mehreren Dateien gespeichert sind und bei Simulationsbeginn dem Verkehrssimulator übergeben werden, darunter wenigstens 7.1. Angaben zum zeitlichen Verlauf der durchschnitthchen Verkehrsmenge in Anrufe pro Zeiteinheit jeweüs pro zu berücksichtigendem IN-Dienst und/oder Diensteteilnehmer und/oder SSP, 7.2. Angaben zu Wahrscheinlichkeiten betreffend das weitere Schicksal eines Anrufs
7.2.1. nach Erhalt einer Weiterbehandlungsinformation vom SCP, z.B. mittlere Gesprächs- bzw. Ansagendauer nach erfolgreicher Vermittlung, Wahrschei n li chkeiten für erfolglose Vermittlung (Besetzt/ Teilnehmer meldet sich nicht),
7.2.2. vor Erhalt einer Weiterbehandlungsinformation vom SCP, z.B. Timeout, Auflegen des Anrufers, wobei eine Ereignisfolge erzeugt wird, indem
7.3. für jedes SimulationszeitintervaU jeweüs pro zu berücksichtigendem IN- Dienst und/oder Diensteteilnehmer und/oder SSP unter der Annahme einer gegebenen Wahrscheinhchkeitsverteüung, vorzugsweise Poisson-Verteüung, und unter Berücksichtigung der entsprechend 7.1. vorgegebenen jeweiligen momentanen Durchschnitts-Verkehrsmenge ein Anruf bzw. Erstereignis (PROVTDE INSTRUCTION) erzeugt und in Abhängigkeit von der Erzeugungszeit in einen Ereigniskalender eingetragen wird,
7.4. einem Anruf bzw. Erstereignis zugeordnete Folgenachrichten bzw. Folgeereignisse (EVENT, EVENT (CALL-END) unter Berücksichtigung der Angaben aus 6.2. erzeugt und in Abhängigkeit von der Erzeugungszeit in den Ereigniskalender eingetragen werden, 7.5. und der Ereigniskalender somit sämthche Erst- und Folgeereignisse in chronologischer Folge enthält. 55
8. Simulator nach Anspruch 1, 6 oder 7, dadurch gekennzeichnet, daß für jeden vom Verkehrssimulator (201, 301, 401) generierten Anruf bzw. generierte IN-Nachricht beim Durchlaufen des Simulators folgende Zeitmarken protokolliert werden: Eine Zeitmarke tl beim Generieren des Anrufs bzw. Erstereignisses, die dem Erzeugungszeitpunkt der Nachricht am SSP entspricht; eine Zeitmarke t4 nach dem Abarbeiten einer Nachricht vom Verkehrssimulator (201, 301, 401) durch den SCP-Simulator (202, 302, 402).
9. Simulator nach einem der Ansprüche 2 bis 7, dadurch gekennzeichnet, daß für jeden vom Verkehrssimulator (201, 301, 401) generierten Anruf beim
Durchlaufen des Simulators folgende Zeitmarken protokolliert werden: Eine Zeitmarke tl beim Generieren des Anrufs bzw. Erstereignisses, die dem Erzeugungszeitpunkt der Nachricht am SSP entspricht; eine Zeitmarke t2 nach dem Abarbeiten einer Nachricht vom Verkehrssimulator durch den SS 7- Simulator (303, 403, 503); eine Zeitmarke t3 nach dem Abarbeiten einer
Nachricht vom SS7-Simulator durch den SCP-Simulator (202, 302, 402); eine Zeitmarke t4 nach dem Abarbeiten einer Nachricht vom SCP-Simulator (202, 302, 402) durch den SS7-Simulator.
10. Simulator nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß
10.1. die vom Verkehrssimulator (201, 301, 401) generierten Ereignisfolgen in eine erste Übergabedatei (203) eingetragen werden, die dem SCP-Simulator übergeben und von diesem bearbeitet wird, wobei zu jedem Ereignis der Zeitpunkt tl, der dem Erzeugungszeitpunkt der Nachricht am SSP entspricht, gespeichert ist,
10.2. die vom SCP-Simulator bearbeiteten Ereignisse in eine zweite Übergabedatei (204) eingetragen werden, die dem Verkehrssimulator übergeben wird, wobei zu jedem Ereignis der Zeitpunkt t4, der dem Erzeugungszeitpunkt einer Folgenachricht am SCP und dem Ankunftszeitpunkt der Nachricht am SSP entspricht, gespeichert ist. (Datei- Modus)
11. Simulator nach Anspruch 2, dadurch gekennzeichnet, daß 11.1. die vom Verkehrssimulator generierten Ereignisfolgen in eine erste Übergabedatei (304, 406) eingetragen werden, die dem SS7-Simulator übergeben und von diesem bearbeitet wird, wobei zu jedem Ereignis der Zeitpunkt tl, der dem Erzeugungszeitpunkt der Nachricht am SSP entspricht, gespeichert ist, 56 11.2. die vom SS7-Simulator bearbeiteten Ereignisse in eine zweite Übergabedatei (305, 407) eingetragen werden, die dem SCP-Simulator übergeben wird, wobei zu jedem Ereignis der Bearbeitungszeitpunkt t2, der dem Ankunftszeitpunkt der Nachricht am SCP entspricht, gespeichert ist, 11.3. die vom SCP-Simulator bearbeiteten Ereignisse in eine dritte Übergabedatei (306, 408) eingetragen werden, die dem SS7-Simulator übergeben wird, wobei zu jedem Ereignis der Zeitpunkt t3, der dem Erzeugungszeitpunkt einer Folgenachricht am SCP entspricht, gespeichert ist, 11.4. die vom SS7-Simulator bearbeiteten Ereignisse in eine vierte Übergabedatei (307, 409) eingetragen werden, die dem Verkehrssimulator übergeben wird, wobei zu jedem Ereignis der Zeitpunkt t4, der dem Ankunftszeitpunkt der Nachricht am SSP entspricht, gespeichert ist.
12. Simulator nach Anspruch 10 oder 11, dadurch gekennzeichnet, daß die Schritte 10.1. und 10.2. bzw. 11.1. bis 11.4 mehrmals nacheinander durchgeführt werden, wobei beim ersten Durchlauf im Schritt 10.1. bzw. 11.1. zur Generierung von Folgeereignissen vom Verkehrssimulator konstante SCP- bzw. SCP- und SS7-Verzögerungszeiten angenommen werden, die in den darauffolgenden Zyklen durch die aus der zweiten bzw. vierten Übergabedatei nach Durchlauf des SCP- bzw. SCP- und SS7-Simulators ermittelten Antwortzeiten modifiziert werden.
13. Simulator nach einem der Ansprüche 1 bis 9, gekennzeichnet durch einen lokalen, dem Verkehrssimulator zugeordneten Ereigniskalender, in welchem vom Verkehrssimulator abzuarbeitende Ereignisse eingetragen sind.
14. Simulator nach einem der Ansprüche 1 bis 9 oder 13, gekennzeichnet durch einen lokalen, dem SS7-Simulator zugeordneten Ereigniskalender, in welchem vom SS7-Simulator abzuarbeitende Ereignisse als Funktion ihrer Zeitmarke und/oder Priorität eingetragen sind.
15. Simulator nach einem der Ansprüche 1 bis 9, 13 oder 14, gekennzeichnet durch einen lokalen, dem SCP-Simulator zugeordneten Ereigniskalender, in welchem vom SCP-Simulator abzuarbeitende Ereignisse als Funktion ihrer Zeitmarke und/oder Priorität eingetragen sind. 57
16. Simulator nach einem der Ansprüche 13 bis 15, dadurch gekennzeichnet, daß ein lokaler Ereigniskalender mehrere ineinander geschachtelte Warteschlangen aufweist, die jeweüs von einer Unterkomponente des Simulationsmoduls abzuarbeitende Ereignisse enthalten.
17. Simulator nach einem der Ansprüche 13 bis 16, gekennzeichnet durch einen globalen Ereigniskalender, der Ereignisse, die Nachrichten zwischen SSP, SCP und gegebenenfaUs dem SS7-System entsprechen, (globale externe Ereignisse) und Verweise auf die lokalen Ereigniskalender der Module Verkehrssimulator und/oder SCP-Simulator und/oder SS7-Simulator (globale interne Ereignisse) als gemeinsame Warteschlange enthält, wobei die Ereignisse als Funktion der Zeit und/oder der Priorität in den globalen Ereigniskalender eingetragen werden. (Online-Modus)
18. Simulator nach Anspruch 17, dadurch gekennzeichnet, daß zur Berücksichtigung von rufunabhängigen Vorgängen innerhalb der Netzkomponenten, z.B. Betriebssystemeingriffen innerhalb der SCP- Prozessoren, rufunabhängige Ereignisse zufäUig erzeugt, in den globalen sowie gegebenenfaUs den entsprechenden lokalen Ereigniskalender eingetragen und vom jeweiligen Simulationsmodul abgearbeitet werden.
19. Simulator nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, daß dem Simulator und den Simulationsmodulen jeweüs eine Simulationsuhr zugeordnet ist, welche während des Abarbeitung eines Ereignisses aus dem globalen bzw. dem jeweiligen lokalen Ereigniskalender stillsteht und bei dessen Beendigung auf den Zeitpunkt des nächsten, im entsprechenden globalen bzw. lokalen Ereigniskalender eingetragenen Ereignisses vorgesteüt wird.
20. Simulator nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, daß ein Simulationsmodul einer externen Nachricht bzw. einem externen Ereignis benutzerdefinierbar eines oder eine Folge von internen Ereignissen mit jeweüs definierter Dauer Δt, zuordnet und die Einzelereignisse in den lokalen Ereigniskalender einträgt. (Erzeugung eines internen Ereignisses) 58
21. Simulator nach Anspruch 20, dadurch gekennzeichnet, daß
21.1. ein Simulationsmodul durch ein in den globalen Ereigniskalender eingetragenes internes Ereignis, das auf den lokalen Ereigniskalender verweist, zur Abarbeitung seines nächsten internen Ereignisses aufgerufen wird,
21.2. nach Abarbeitung des Ereignisses die interne Simulationsuhr angepaßt wird, wobei
21.3.1. faUs ein weiteres zu der Prozeßkette gehöriges Ereignis vorhanden ist, ein Verweis auf dieses folgende interne Ereignis mit der aktueUen internen Simulationszeit in den globalen Ereigniskalender eingetragen wird
21.3.2. oder, faUs das aktueU bearbeitete Ereignis das letzte einer Prozeßkette darsteUt, ein externes Ereignis vom Simulationsmodul erzeugt und mit der aktueUen internen Simulationszeit in den globalen Ereigniskalender eingetragen wird.
22. Simulator nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, daß Telefon-Normalverkehr in die Verkehrssimulation einbezogen wird.
23. Simulator nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, daß in konstanten Zeitintervallen oder für vorbestimmbare
Simulationszeitpunkte wenigstens eine der folgenden Netzauslastungs-
Größen mit der dazugehörigen Simulationszeit in eine Ausgabedatei geschrieben werden:
Anzahl der vom Verkehrssimulator erzeugten, in das IN gelangenden Anrufe pro Zeiteinheit,
Anzahl der Nachrichten, die sich in Bearbeitung im SS7-Simulator auf dem
Weg zum SCP-Simulator befinden, Anzahl der Nachrichten im SCP-Simulator,
Anzahl der Nachrichten, die sich in Bearbeitung im SS7-Simulator auf dem
Weg zum Verkehrssimulator befinden.
24. Simulator nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, daß der SCP-Simulator in konstanten ZeitintervaUen oder für vorbestimmbare Simulationszeitpunkte die CPU-Auslastung und/oder Warteschlangenlänge und/oder Anzahl bearbeiteter Prozesse pro Zeiteinheit (Dispatches), jeweüs 59 individualisiert nach CPU-Nummer und oder gemittelt über aüe CPUs und/oder minimaler und maximaler Wert einer CPU als SCP-Statistik-Größen mit der dazugehörigen Simulationszeit in eine Ausgabedatei schreibt.
25. Simulator nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, daß in konstanten Zeitintervaüen oder für vorbestimmbare Simulationszeitpunkte SSP-spezifisch die Anzahl der belegten Leitungen zu einer VermittlungssteUe und/oder im IN protokolliert und in eine Datei geschrieben wird.
26. Simulator nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, daß eine Benutzeroberfläche vorgesehen ist, die als Eingabeelement zur Generierung einer Simulation durch Eingabe von Simulationsparametern dient, die Verwaltung der Konfigurationsdateien vornimmt sowie imstande ist, die Simulationsergebnisse graphisch auszugeben.
27. Simulator nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, daß ein Modul zur ereignisorientierten Simulation weiterer Netzkomponenten vorgesehen ist, insbesondere ein Modul zur Simulation des Service Management Systems (SMS) und/oder zur Simulation von Intelligenten Peripherals (IPs).
PCT/EP1999/001141 1998-03-16 1999-02-23 Simulator zur simulation eines intelligenten netzwerks WO1999048306A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP99939863A EP1013109A1 (de) 1998-03-16 1999-02-23 Simulator zur simulation eines intelligenten netzwerks
US09/423,954 US6650731B1 (en) 1998-03-16 1999-02-23 Simulator for simulating an intelligent network
HU0400884A HUP0400884A2 (en) 1998-03-16 1999-02-23 Simulator for simulating an intelligent network
CA002289515A CA2289515A1 (en) 1998-03-16 1999-02-23 Simulator for simulating an intelligent network
JP54644799A JP2001526876A (ja) 1998-03-16 1999-02-23 インテリジェントネットワークをシミュレーションするためのシミュレータ

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE19811097A DE19811097A1 (de) 1998-03-16 1998-03-16 Simulator zur Simulation eines intelliegenten Netzwerks
DE19811097.9 1998-03-16

Publications (1)

Publication Number Publication Date
WO1999048306A1 true WO1999048306A1 (de) 1999-09-23

Family

ID=7860887

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP1999/001141 WO1999048306A1 (de) 1998-03-16 1999-02-23 Simulator zur simulation eines intelligenten netzwerks

Country Status (8)

Country Link
US (1) US6650731B1 (de)
EP (1) EP1013109A1 (de)
JP (1) JP2001526876A (de)
CN (1) CN1258418A (de)
CA (1) CA2289515A1 (de)
DE (1) DE19811097A1 (de)
HU (1) HUP0400884A2 (de)
WO (1) WO1999048306A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1311663C (zh) * 2003-07-21 2007-04-18 华为技术有限公司 一种判断智能业务测试覆盖率高低的方法
GB2469509A (en) * 2009-04-16 2010-10-20 Aircom Internat Network modelling method
US9198110B2 (en) 2009-04-16 2015-11-24 Aircom Internatioal Ltd. Modelling apparatus and method
US10291481B2 (en) 2009-04-16 2019-05-14 Teoco Corporation Modelling apparatus and method

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010051862A1 (en) * 2000-06-09 2001-12-13 Fujitsu Limited Simulator, simulation method, and a computer product
ITTO20010180A1 (it) * 2001-03-01 2002-09-01 Cselt Centro Studi Lab Telecom Procedimento e sistema per il controllo della configurazione dei nodidi una rete per telecomunicazione.
US7158627B1 (en) * 2001-03-29 2007-01-02 Sonus Networks, Inc. Method and system for inhibiting softswitch overload
US20020188433A1 (en) * 2001-06-06 2002-12-12 Honeywell International Inc. Generic device simulator for process control
GB2379125B (en) * 2001-06-21 2003-11-12 Toshiba Kk Communication apparatus private branch exchange apparatus maintenance terminal apparatus and simulation method
US7774440B1 (en) * 2001-07-25 2010-08-10 Scalable Network Technologies, Inc. Method and system for enhancing performance of a physical network under real-time control using simulation of a reference model
DE10307408B3 (de) * 2003-02-20 2004-09-02 Radioplan Gmbh Verfahren zur Ablaufsteuerung von sequentiellen objektorientierten Systemsimulationen der Kommunikation in Mobilfunknetzen
AU2003292534A1 (en) * 2003-11-21 2005-06-08 Telecom Italia S.P.A. Method and system for simulating communications networks, object and computer program product therefor
JP4610240B2 (ja) * 2004-06-24 2011-01-12 富士通株式会社 分析プログラム、分析方法及び分析装置
DE102004043028A1 (de) * 2004-09-06 2006-03-30 Siemens Ag Verfahren zur Beschränkung des Zugangs zu einem Televoting-Dienst auf Basis der Rufnummer eines Teilnehmers
US7369977B1 (en) * 2004-09-20 2008-05-06 The Mathworks, Inc. System and method for modeling timeouts in discrete event execution
US9197533B1 (en) 2005-05-09 2015-11-24 Cisco Technology, Inc. Technique for maintaining and enforcing relative policies with thresholds
US20070067296A1 (en) * 2005-08-19 2007-03-22 Malloy Patrick J Network capacity planning
US20070271079A1 (en) * 2006-05-17 2007-11-22 Kentaro Oguchi Simulator for Vehicle Radio Propagation Including Shadowing Effects
US20090099827A1 (en) * 2007-10-16 2009-04-16 Sony Corporation System and method for effectively performing a network simulation procedure
US8793117B1 (en) * 2008-04-16 2014-07-29 Scalable Network Technologies, Inc. System and method for virtualization of networking system software via emulation
US8326977B2 (en) * 2008-07-16 2012-12-04 Fujitsu Limited Recording medium storing system analyzing program, system analyzing apparatus, and system analyzing method
US20100017486A1 (en) * 2008-07-16 2010-01-21 Fujitsu Limited System analyzing program, system analyzing apparatus, and system analyzing method
JP5169614B2 (ja) * 2008-08-19 2013-03-27 富士通株式会社 システム分析プログラム、システム分析装置、システム分析方法
US20100066731A1 (en) * 2008-09-16 2010-03-18 James Calvin Vecore Configurator Process and System
US9210050B2 (en) * 2009-07-09 2015-12-08 Centurylink Intellectual Property Llc System and method for a testing vector and associated performance map
US8885636B2 (en) * 2009-09-01 2014-11-11 International Business Machines Corporation Method and system for platform-independent VoIP dial plan design, validation, and deployment
US20120084110A1 (en) * 2010-10-05 2012-04-05 M3 Technology, Inc. System and method for smart oil, gas and chemical process scheduling
US9065916B2 (en) * 2012-06-01 2015-06-23 Callpromise, Llc System and method for virtual queuing of calls
US9958843B2 (en) * 2012-11-07 2018-05-01 Hitachi, Ltd. System and program for managing management target system
WO2015002714A1 (en) * 2013-07-02 2015-01-08 Seven Networks, Inc. Modeling network signaling in a mobile network
CN103517311B (zh) * 2013-09-11 2017-02-22 百度在线网络技术（北京）有限公司 一种模拟无线网络的方法与装置
DE102015002367A1 (de) 2014-03-02 2015-09-03 Gabriele Trinkel Sichere Übertragung von Daten und Skalierung, Regelung zur Überlastabwehr in der Cloud und Cloud Computing
EP3217713B1 (de) 2014-11-28 2020-09-30 Huawei Technologies Co., Ltd. Verfahren und vorrichtung zur erfassung einer dienstverteilung
US10282062B2 (en) 2016-10-03 2019-05-07 Sas Institute Inc. Techniques for repairable system simulations
US10534588B2 (en) * 2018-06-08 2020-01-14 Sap Se Data processing simulator with simulator module and data elements

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5359649A (en) * 1991-10-02 1994-10-25 Telefonaktiebolaget L M Ericsson Congestion tuning of telecommunications networks
US5621670A (en) * 1991-08-01 1997-04-15 Fujitsu Limited Communication service simulator and a communication service specification verifying method
EP0781020A2 (de) * 1995-12-21 1997-06-25 Ericsson Inc. Testvorrichtungen in einem intelligenten Netzwerksystem

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5594782A (en) * 1994-02-24 1997-01-14 Gte Mobile Communications Service Corporation Multiple mode personal wireless communications system
US5805570A (en) * 1995-05-02 1998-09-08 Merge Technologies Group, Inc. Method of simulating an ISDN-BRI central office switch using a single microcomputer
US5787147A (en) * 1995-12-21 1998-07-28 Ericsson Inc. Test message generator in a telecommunications network
JPH09321869A (ja) * 1996-05-31 1997-12-12 Nec Corp 呼情報試験方法とその装置
US5940472A (en) * 1996-12-16 1999-08-17 Mci Communications Corporation Intelligent services network test system
US5982852A (en) * 1997-01-31 1999-11-09 3Com Corporation Line performance test system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5621670A (en) * 1991-08-01 1997-04-15 Fujitsu Limited Communication service simulator and a communication service specification verifying method
US5359649A (en) * 1991-10-02 1994-10-25 Telefonaktiebolaget L M Ericsson Congestion tuning of telecommunications networks
EP0781020A2 (de) * 1995-12-21 1997-06-25 Ericsson Inc. Testvorrichtungen in einem intelligenten Netzwerksystem

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SMITH D E: "ENSURING ROBUST CALL THROUGHPUT AND FAIRNESS FOR SCP OVERLOAD CONTROLS", IEEE / ACM TRANSACTIONS ON NETWORKING, vol. 3, no. 5, 1 October 1995 (1995-10-01), pages 538 - 548, XP000543255 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1311663C (zh) * 2003-07-21 2007-04-18 华为技术有限公司 一种判断智能业务测试覆盖率高低的方法
GB2469509A (en) * 2009-04-16 2010-10-20 Aircom Internat Network modelling method
GB2469509B (en) * 2009-04-16 2011-06-29 Aircom Internat Ltd Modelling apparatus and method
US8654676B2 (en) 2009-04-16 2014-02-18 Teoco Corporation Modelling apparatus and method
US9198110B2 (en) 2009-04-16 2015-11-24 Aircom Internatioal Ltd. Modelling apparatus and method
US10291481B2 (en) 2009-04-16 2019-05-14 Teoco Corporation Modelling apparatus and method

Also Published As

Publication number Publication date
CA2289515A1 (en) 1999-09-23
EP1013109A1 (de) 2000-06-28
US6650731B1 (en) 2003-11-18
JP2001526876A (ja) 2001-12-18
DE19811097A1 (de) 1999-09-23
CN1258418A (zh) 2000-06-28
HUP0400884A2 (en) 2004-08-30

Similar Documents

Publication Publication Date Title
EP1013109A1 (de) Simulator zur simulation eines intelligenten netzwerks
DE69829165T2 (de) Überlastregelung in einem kommunikationsnetzwerk
DE69233618T2 (de) Verarbeitungssystem zur Leitweglenkung für Teilnehmeranrufe
DE69631373T2 (de) Abrechnungsverwaltung für telekommunikationsbenutzung
DE69632888T2 (de) Dienst- und Informationsverwaltungssystem für ein Telekommunikationsnetzwerk
DE69837010T2 (de) System und verfahren zum steuern des zugriffs auf eine vermittlungsdatenbank
DE602004004321T2 (de) Vorrichtung und Verfahren zur Echtzeitbeurteilung einer Netzverwaltungsregel
DE69733543T2 (de) Verfahren zum Anbieten von wenigstens einem Dienst an Fernmeldenetzbenutzern
DE69732221T2 (de) Verfahren zum Anbieten von einem Dienst an Fernmeldenetzbenutzern
DE102006002247A1 (de) Verfahren und System zum Aktualisieren von Echtzeitdaten zwischen Intervallen
DE69332927T2 (de) Gerät zur Verwaltung eines Elementverwalters für ein Fernmeldevermittlungssystem
DE69731182T2 (de) Nachrichtenverfahren zwischen einer Dienstvermittlungsstelle und einer Dienstkontrolleinrichtung in einem Fernmeldenetz
DE19919976A1 (de) Verfahren und Vorrichtung zum Übertragen eines eingebetteten Nebenstellensystems auf einen Personalcomputer
DE69825560T2 (de) Intelligentes netzwerk mit einer verteilten dienststeuerungsfunktion
DE60308776T2 (de) Beherrschen von Abhängigkeiten von individualisierten Leistungsmerkmalen in der IP Telephonie mittels deontischen Befehlsbäumen und Ablaufsoperatoren
DE69830421T2 (de) Vorverarbeitung von ereignissen zur zusammenstellung eines berichtes
DE69836347T2 (de) Dienstinteraktion in einem intelligenten netzwerk
DE60318263T2 (de) Kommunikationsanfrageverarbeitungssystem und -verfahren
DE19720274C2 (de) Kommunikationssystem, Verfahren und Verarbeitungseinrichtung zum Vermitteln von Anrufen über ein zwischen zwei lokalen Netzen angeordnetes Übertragungsnetz
EP1371236B1 (de) Verfahren zur selektiven und gesammelten weiterleitung von meldungen in einem tmn-netzwerk
EP0850545A1 (de) Ablaufumgebungssystem für service-applikationen eines kommunikationsnetzes
DE69828694T2 (de) Intelligente periphere diensteinheit
EP1317150B1 (de) Verfahren zum Übermitteln eines Kennzeichendatums einer Netzknoteneinheit, zugehörige Vorrichtung und zugehöriges Programm
EP0967776A2 (de) Verbindungsaufbauverfahren Dienststeuereinheit und Kommunikationsnetz
DE10023624A1 (de) Dienst-Einheit

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 99800294.1

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 1999939863

Country of ref document: EP

AK Designated states

Kind code of ref document: A1

Designated state(s): CA CN HU JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

ENP Entry into the national phase

Ref document number: 2289515

Country of ref document: CA

Ref document number: 2289515

Country of ref document: CA

Kind code of ref document: A

Ref document number: 1999 546447

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 09423954

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1999939863

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1999939863

Country of ref document: EP