WO2010072268A1 - Appel d'essais virtuels - Google Patents

Appel d'essais virtuels Download PDF

Info

Publication number
WO2010072268A1
WO2010072268A1 PCT/EP2008/068241 EP2008068241W WO2010072268A1 WO 2010072268 A1 WO2010072268 A1 WO 2010072268A1 EP 2008068241 W EP2008068241 W EP 2008068241W WO 2010072268 A1 WO2010072268 A1 WO 2010072268A1
Authority
WO
WIPO (PCT)
Prior art keywords
use case
case logic
data
network
communication network
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/EP2008/068241
Other languages
English (en)
Inventor
Kari Olavi Einamo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks Oy
Original Assignee
Nokia Siemens Networks Oy
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 Nokia Siemens Networks Oy filed Critical Nokia Siemens Networks Oy
Priority to PCT/EP2008/068241 priority Critical patent/WO2010072268A1/fr
Publication of WO2010072268A1 publication Critical patent/WO2010072268A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H04L43/55—Testing of service level quality, e.g. simulating service usage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/20—Arrangements for monitoring or testing data switching networks the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV

Definitions

  • the present invention relates to network management and fault detection in telecommunication networks.
  • the present invention relates to implementing virtual test calls to test that a service can be provided.
  • Telecommunication networks are becoming more and more complex in that the telecommunication networks now include signifi- cant numbers of network elements which communicate with each other and a network management system (NMS) over numerous communication channels.
  • NMS network management system
  • Each of the network elements comprise a significant amount of configuration information that must be synchronised with the other network elements in the network.
  • This configuration information is known as static information as the configuration information is controlled and only altered occasionally by the NMS.
  • the configuration information is considered static as it does not change automatically in response to the current operating conditions of the network but only in response to management personnel making changes via the NMS.
  • the network elements also comprise a significant amount of dynamically changed information.
  • This information is dynamic as it changes based on events that occur in the network and the network elements themselves.
  • dynamic information could include the status of communication links, status of hardware and so on.
  • the network elements may generate alarms relating to the dynamic information, for example, an alarm that indicates a particular communication link or a particular piece of hard- ware in the network element has a fault. These alarms may be recognised by the NMS but the individual alarms that may be generated by a particular fault do not provide the NMS with a complete picture of whether network level and end user func- tionality has been affected.
  • a method comprising accessing a predefined use case logic wherein said use case logic comprises at least one use case logic command which represent a real function in a communication network; obtaining static data relating to said communication network; obtaining dynamic data relating to said communication network; and determining whether each of the at least one use case logic commands are executed suc- cessfully based on at least one of the static data and the dynamic data.
  • the present invention advantageously enables a method of testing a communication network using predefined use case logic and determining based on the static data and/or dynamic data of the communication network whether the use case logic is successfully executed.
  • the predefined use case logic is analysed using the static data and/or the dynamic data then it can determine whether the real-life ser- vice that the use case logic models would also be successful if executed on the real communication network.
  • the method of the present invention enables a virtual representation of a service or test to be analysed using the actual static data and/or dynamic data of the communication network .
  • the use case logic commands represent a real function that takes place in a network element in the network such as the Global Title Translation, link availability and so on.
  • Each use case logic command is part of the whole functionality that each of the use case logic represents.
  • the use case logic represents the handling of Short Messaging Service (SMS) in a Visited Mobile Switching Centre (VMSC)
  • the real functionality can be divided to several functions including reading subscription data from a subscription database, perform Global Title (GT) translation for routing purposes, check whether subscriber is allowed to use SMS, update statistics, create charging ticket, and so on each of which is mirrored in the use case logic by the use case logic commands .
  • SMS Short Messaging Service
  • VMSC Visited Mobile Switching Centre
  • the present invention has the advantage that it can supervise the communication network' s health proactively and without disturbing the network functionality or using network capacity.
  • the method of the present invention may be performed periodically and therefore activated using a scheduling system.
  • the method may also be performed when triggered be, for example, by an operator or by an event that has occurred.
  • the step of accessing a predefined use case logic may comprise reading the use case logic from a use case logic container .
  • the predefined use case logic may represent a user service and the user service may be, for example, SMS delivery, location update, handover between cells, call between different subscribers and so on.
  • the predefined use case logic may represent a defined network test of either part or the whole of the communication network.
  • the network tests may be, for example, GT routing between given network elements, ATM routing between given network elements, tests for given subscribers or subscriber ran- ges (Mobile Station International Subscriber Directory Number (MSISDN) ranges), between given network elements, between ranges of network elements, over a complete mesh and so on.
  • MSISDN Mobile Station International Subscriber Directory Number
  • the use case logic may comprise two or more use case logic commands.
  • the step of determining whether each of the at least one use case logic commands are executed successfully may further comprise traversing through the at least one use case logic commands and determining whether each of said use case logic commands is successfully executed prior to executing the next use case logic command.
  • the use case logic command may define a starting network ele- ment and a destination network element and the step of determining whether said use case logic command is successfully executed may further comprise analysing the static data to determine a next signaling transfer point in said communication network; analysing the dynamic data to determine a link status to the next signaling transfer point; and repeating the steps of analysing until the destination network element has been reached.
  • the use case logic may comprise several use case logic commands each of which define a real function in the communication network.
  • the use case logic may comprise use case logic commands that describe the functions needed in transmitting the SMS from the Mobile
  • SMSC Short Message Service Centre
  • HLR Home Location register
  • the use case logic commands represent the internal functions of the network elements in the network, for example, GT translation is performed, link status is checked etc., in or- der to simulate the service being tested. If the simulation is performed successfully based on the current configuration and dynamic data of all network elements then the actual service if performed in the network, for example, an actual SMS is transmitted from subscriber A to subscriber B, it will al- so be successful. However, if the simulation is unsuccessful then the network operator can be informed and the network operator can take corrective measures to ensure that the service will be successful.
  • the first use case logic command is executed, which in this example is the command that represents the real function needed in transmitting the SMS from the MSC of subscriber A to the SMSC of subscriber A.
  • this will typically involve the SMS being routed along sev- eral links between several intermediate network elements which are the signaling transfer points. Therefore, the method may analyse the network configuration and the configuration of the network elements, which is the static data, and the dynamic data relating to the status of the links between the intermediate nodes, e.g. the signaling transfer points.
  • the method may traverse through the network until the SMSC of subscriber A is reached.
  • the static data may represent configuration and topology data of network elements and of said communication network.
  • the step of obtaining the static data may comprise sending a request for the static data to a configuration and topology data server; and receiving the static data from the configuration and topology data server.
  • the step of obtaining said static data from the configuration and topology data server may be performed once and the static data is cached such that the static data is subsequently obtained from said cache.
  • the static data would not need to be obtained every time a predefined use case logic is executed.
  • the step of obtaining the static data from the configuration and topology server may be performed each time the static data is required.
  • the dynamic data represents dynamically changing data in net- work elements of said communication network.
  • the dynamic data may relate to the status of a link in the communication network, state of Signaling Connection Control Part (SCCP) subsystems, state of signaling points, availability of physical resources like CPU nodes, disk units, Ether- net connections, the state of logical resources like databases, directory services and so on.
  • SCCP Signaling Connection Control Part
  • the dynamic data may include any data that will change dynamically in the network.
  • the step of obtaining the dynamic data may further comprise sending a request for said static data to at least one of a network element or an element management system; and receiving the dynamic data.
  • the dynamic data can be obtained directly from the network elements themselves and/or from the element management system. If the dynamic data is obtained form the network elements themselves then, for example, with an MSC server network element the same Man- Machine Language (MML) interface that is used to configure the MSC server can also be used for requesting the dynamic data, such as the link, route and hardware node status. Other network elements may require a command line session in order to obtain the dynamic data.
  • MML Man- Machine Language
  • the MSC server has an MML interface that is used for configuring the system and for requesting dynamic information.
  • the MSC server may have any other interface that can be used for obtaining dynamic data from the MSC server.
  • the step of obtaining the dynamic data from at least one of the network elements and the element management system may be performed each time the dynamic data is required.
  • the dynamic data may also be cached due to performance reasons and this step of caching the dynamic data will be performed as frequently as required.
  • the method may further comprise sending a request for subscription data for a subscriber from a subscription management system; and receiving the subscription data.
  • the subscription data may be required for a particular predefined use case logic. For example, in the SMS delivery use case logic described above the subscription data may be required in order to determine the MSC and the SMSC of subscriber A and the HLR and MSC of subscriber B.
  • the method may further comprise determining that a predefined use case logic is unsuccessful and sending an alarm to a network management system.
  • a server adapted to access a predefined use case logic whe- rein said use case logic comprises at least one use case logic command which represent a real function in a communication network; obtain static data relating to said communication network; obtain dynamic data relating to said communication network; and determine whether each of the at least one use case logic commands are executed successfully based on at least one of the static data and the dynamic data.
  • a computer program product comprising computer readable code for accessing a predefined use case logic wherein said use case logic comprises at least one use case logic command which represent a real function in a communication network; obtaining static data relating to said communication network; obtaining dynamic data relating to said communication net- work; and determining whether each of the at least one use case logic commands are executed successfully based on at least one of the static data and the dynamic data.
  • the embodiments may provide a method of supervising network health proactively and without disturbing network functionality.
  • the method obtains the static and dynamic information regarding the communication network and allows virtual test calls relating to defined use cases to be tested to determine whether the use cases will or will not succeed in the current state of the communication network.
  • Figure 1 shows a diagrammatic representation of the network and management system according to the embodiments of the present invention.
  • Figure 2 shows a diagrammatic representation of the architecture of the virtual test call in accordance with the embodiments of the present invention.
  • Figure 3 shows a flow diagram for an example of SMS delivery.
  • NMS Network Management System
  • a communication network comprises a managed network 101 which includes any number of network elements 102.
  • the network elements 102 are operatively connected to an NMS 104 via network management connections 103.
  • the virtual test call application 105a, 105b providing the virtual test call functionality may either be located 105a in the NMS 104 or be located 105b in a separate system or on a separate server that has access to information in the NMS 104 and has the capability to interface with and access the man- aged network elements 102.
  • the embodiments of the present invention will be described in relation to a specific example of testing that an SMS can be transmitted from one subscriber to another subscriber. How- ever, as a person skilled in the art will appreciate, the virtual test call functionality of the present invention may be used to simulate and test any service or functionality that can be provided in a communication network and by the network operator.
  • FIG. 2 shows the virtual test call application 201 providing the virtual test call functionality in a high level diagrammatic representation according to an embodiment.
  • the virtual test call application 201 comprises a scheduler 202, a test launch trigger 203, test case parameter database 204, a result and reports database 205, a use case logic container 206, an access services module 207 and a network element logic services module 208.
  • the use case logic container 206 comprises various predefined use case logic implementations 209.
  • the use case logic container 206 stores the predefined use case logic 209 which may be defined for user/control plane scenarios that test ser- vices in the communication network 101, for example:
  • use case logic 209 that do not test whole end user services but may test functionality between network elements, for example, use cases that test GT routing or ATM routing between given network elements.
  • Predefined use case logic implementations 209 may also be defined for given subscribers or subscriber ranges (MSISDN ranges) and/or defined between given network elements, ranges of network elements or the complete communication network.
  • the uses cases 209 may also be executed either periodically using the scheduler module 202 or on request using the test launch trigger module 203.
  • any number of predefined use case logic implementations 209 may be defined for testing the functionality and availability of the communication network.
  • the use case logic container 206 may be implemented as a framework inside the Java Virtual Machine which provides flexibility in the implementation of the use cases. Further use case logic implementations can be added by programming new use case logic components.
  • the use case logic container 206 may be imple- mented using A Business Process Execution Language (BPEL)
  • BPEL A Business Process Execution Language
  • BPEL Service Orientated Architecture
  • use case container 206 may be implemented using any acceptable means which allows use case logic implementations to be defined, stored and executed.
  • the access services module 207 com- prises several modules that interface with and can obtain data from and/or provide data to several entities.
  • a subscription data access module 210 can interface with a subscription management system 215 in order to obtain data on subscriptions in the network.
  • a Fault Management (FM) /Performance Management (PM) /Configuration Management (CM) access module 211 can interface with a network management system 216 and, in particu- lar, provide the interface to Fault Management data 217, Performance Management data 218 and Configuration Management and network topology data 219.
  • a network element access service module 212 can interface with network elements 220 directly or obtain data from the network elements 220 via an Element Management System 221. The network element access service module 212 can retrieve data regarding the dynamic state of the network elements 220 and may also be used for accessing subscriber' s data from, for example, an entity such as a Home Location register (HLR) .
  • HLR Home Location register
  • the access services module 207 is used to hide the complexity of the underlying communication network from the use case logic implementations 209 contained in the use case logic container 206.
  • the access services module 207 is comprised of modules that provide the functionality to interface with the entities from which the access services module 207 can obtain data from in order to be able to perform the virtual test calls and execute the use cases defined in the use case logic container 206.
  • the access service module 207 may also report any faults via an alarm event to the network management system 216 in the event that a fault was detected on executing a use case.
  • the access service module 207 may also comprise further modules 222 as required in order to retrieve and obtain the data required in order to perform the virtual test calls and execute the predefined use case logic 209.
  • the network element logic services module 208 may comprise several modules that provide the capabilities to use the configuration data retrieved from the communication network in a similar manner to how the network elements use the configuration data. This enables the vir- tual test call application to be able to execute the use cases virtually. In other words, the virtual test cases are not performed in the actual communication network but on a virtual representation of the communication network using the current static and dynamic information obtained from the network management systems and the network elements.
  • a simplified version of the state of the communication network in terms of both the static and dynamic state information, is required in order to perform the virtual test calls.
  • the state of the communication network that depends directly on the configuration data is required and the hard coded functionalities of the network elements can be omitted.
  • the network element logic services module 208 may comprise a Global Title (GT) translation service module 213.
  • the GT translation service module 213 provides the functionality of global title translation in which when a GT address and originating network element is provided the GT translation service module 213 analyses the configuration management data obtained from the Configuration Management and network topology database 219 in order to determine which signalling point the provided GT address and originating network element re- fers to.
  • the analysis performed on the Configuration Management and network topology data may include analysing the records from the Configuration Management and network topology database 219 and traversing through the records until the signalling point has been determined.
  • the GT translation service module 213 analyses whether the GT translation is rout- able using the Configuration Management and network topology data.
  • the GT translation service module 213 analyses the GT translation configuration for each Signalling Connection Control Part (SCCP) Signalling Transfer Point (STP) and the link states.
  • SCCP is a protocol layer in the known SS7 stack and the GT address is used for routing at SCCP layer.
  • SCCP STP is network element functionality that is capable of performing protocol message routing at SCCP layer e.g. using GT addresses .
  • the GT translation service module 213 accesses the GT translation configuration data from, for example, the CM data storage.
  • a GT address is provided to the GT translation service module 213 it checks whether GT translation exists for that given GT address. In practice this means traversing the analysis tree until a result is found or when it is not possible to continue anymore and therefore no result is found for a given GT address.
  • the result of the GT analysis typically includes the Signal- ling Point Code (SPC) of the next STP, for example, the next network element, to where the message would be routed if the message was actually being transmitted through the network. If a result is found then the accessibility of the resulting next STP could be checked from the dynamically updated status information, for example, to determine whether the link to the next STP is available and operational.
  • SPC Signal- ling Point Code
  • the Configuration Management and network topology data may either be obtained at the time that the GT translation ser- vice 213 requires the data or has been obtained previously.
  • the GT translation service 213 may also obtain data from the network elements 220.
  • a digit analysis service module 214 may also be provided which performs digit analysis. Based on a given ISDN number and a given network element the digit analysis service module 214 determines what is to be done with the virtual test call next. Digit analysis is part of call processing in MSCs which analyses the called party number to determine which MSC the call or message should be routed to, or whether the current MSC is the target MSC or whether the MSC should perform a HLR query and so on.
  • the digit analysis typically requires a similar analysis tree as described above for GT translation. In other words a tree structure is typically traversed using the provided phone number to locate a result record.
  • the GT translation and digit analysis service modules are described are examples of the service modules that can be implemented in the embodiments of the present invention. As a person skilled in the art will appreciate, there may be many more services implemented using service modules depending on the use cases being implemented. Accordingly, the Network Element Logic service module 208 may also comprise any number of further modules 223 as required in order to provide the functionality of analysing the configuration management and topology data when performing a virtual test call .
  • the virtual test call functionality enables a predefined use case logic, which represents real- life functions in a communication network, to be tested on a virtual representation of the communication network using real static data and dynamic data from the communication network. Therefore, the virtual test call functionality allows the health of the network to be supervised proactively and without disturbing network functionality and without using network capacity. Accordingly, the virtual test call functionality is provided by several modules as shown in Figure 2. However, the modules described as part of the virtual test call functionality are examples only and may not always be used to implement each of the defined use case logic implementations. Moreover, several further modules can be included in the virtual test call functionality to enable the simulation and testing of all the services and functionality provided by the network and network operator.
  • an example of the virtual test call functionality is shown in executing a defined use case logic for simulating the delivery of an SMS message in the communication network.
  • the virtual test call application 201 that provides the virtual test call functionality comprises several modules as described hereinabove in relation to Figure 2.
  • the predefined use case implementations can be initiated by the scheduler module, e.g. at a predetermined scheduled time, or initiated by the test launch triggering module, e.g. when triggered by an operator of the NMS or in response to an event in the communication network.
  • the predefined use case logic is therefore a series of use case logic commands each of which is executed in turn in order to determine whether the service the predefined use case logic represents would, if executed in reality on the actual communication network, be successful.
  • the predefined use case logic for the SMS delivery virtual test 209 is provided with the MSISDN of subscriber A and the MSISDN of subscriber B. The predefined use case logic 209 can then perform a test of the communication network in order to establish whether an SMS can be successfully delivered from subscriber A to subscriber B.
  • the test is performed virtually in that the virtual test call application 201 uses both static and dynamic data on the state of the communication network to create a virtual representation of the commu- nication network which is analysed in order to determine the susses or failure of a particular predefined use case logic. If the virtual test call application determines that the predefined use case logic 209 would fail then the virtual test call application 201 may inform the NMS 216 via an alarm event that there is a problem in the communication network.
  • the SMS delivery use case logic 209 is read from the use case logic container 206.
  • step 301 the first use case logic command in the predefined use case logic for the SMS delivery test is performed.
  • the subscription data access module 210 requests subscriber A' s subscription data from the sub- scription management system 215 and returns 303 subscriber
  • the subscription data for subscriber B is also read from the subscription management system 215 via the subscription data access module 210 of the Access Service module 207 and returned to the predefined use case logic 209 in the same manner as described above for subscriber A.
  • the predefined use case logic defines the use case logic commands for determining that, given the static and dynamic data regarding the actual state of the network elements 220 and the communication links, the predefined use case logic will successfully be completed. If the predefined use case logic 209 is successfully completed then it is determined that, given the actual status of the real communication network, the actual delivery of the SMS from subscriber A to subscriber B would also be successful.
  • the process then checks the first step of routing the SMS message in the communication network.
  • step 306 the use case logic command:
  • the address of both of subscriber A' s MSC and SMSC are known to the use case logic for the SMS delivery from subscriber A' s subscription data that was requested from the subscription management system 215 in the earlier steps of the predefined use case logic 209 for the SMS delivery.
  • the GT translation service module 213 on receipt of the use case logic command analyses the communication network data in order to determine whether the transmission of an SMS between subscriber A' s MSC and SMSC will be successful.
  • the GT translation service module 213 reads analysis records from the configuration management and topology server
  • next STP may be an intermediate network element that the SMS will have to traverse when it is transmitted from the MSC to the SMSC of subscriber A or the next STP may be the destination address of the SMSC.
  • GT analysis is typically implemented using an analysis tree which comprises a collection of records. Sub-records inside the records are then indexed with the digit to be analysed.
  • next records there can be any number of next records (if analysis is to continue) or an index of results (if the analysis is complete) .
  • the digits of GT are typically proc- essed one by one jumping from one record to the next until a result is determined or it is not possible to continue with the analysis.
  • the GT translation service module 213 in step 308 sends a request to the network element access service module 212 of the access services module 207 for the dynamic data relating to the network element
  • the network element access service module 212 sends a request 309 to the network element 220 for its dynamic data relating to the current state of the network element 220 and the communication links that are connected to the network element 220. As described hereinabove, the network element access service module 212 may alternatively request the dynamic data from the element management system.
  • the dynamic data from the network element 220 corresponding to the STP is returned to the GT translation service module 213 via the network element services module 212 and the status of the communication link from the network element STP towards the next SPC is determined from the received dynamic data .
  • the virtual test call application 201 may then report the failure to the NMS via, for example, an alarm event.
  • step 309 the GT transla- tion service module 213 checks whether the SMSC for subscriber A has been reached. If the SMSC for subscriber A has not yet been reached the GT translation service module 213 repeats steps 307 to 309 in order to traverse through the virtual representation of the communication network along the path that the SMS will take in order to arrive at the SMSC for subscriber A. For each of the use case logic commands it is determined, using the actual static and dynamic status data of the communication network, whether or not the use case logic command would succeed and therefore the actual SMS delivery between subscriber A' s MSC and SMSC would succeed.
  • the GT translation service module 213 reports 311 to the predefined use case logic 209 for the SMS delivery test that the SMS, based on the current static and dynamic state data of the communication network, will successfully be transmitted from the MSC of subscriber A to the SMSC of subscriber A.
  • step 312 the same steps as described above are applied to each of the further use case logic commands that are defined in the predefined use case logic 209.
  • the further use case logic commands in the predefined use case logic 209 are exe- cuted and analysed in turn until either one of the use case logic commands fail or all of the use case logic commands have been executed and analysed.
  • the next use case logic command to be analysed in the same manner as described above defines the GT routing between the SMSC for subscriber A to the Home Location Register (HLR) for subscriber B and final use case logic command defines the GT routing between the SMSC for subscriber A and the MSC for subscriber B.
  • HLR Home Location Register
  • the GT translation service module 213 determines whether each of the use case logic commands defined in the predefined use case logic 209 can be successfully completed based on the static data and/or the dynamic data of the communication network. Therefore, if the predefined use case logic success- fully completes then it is determined that the real service, which is being modelled or simulated by the defined use case logic 209, would also be successful if performed in the actual communication network.
  • the preferred embodiment has been described using predefined use case logic for an SMS delivery between subscriber A and subscriber B. However, as will be appreciated by a person skilled in the art the same analysis process can be applied to any use case logic that is defined by a series of use case logic commands.
  • the actual static data of the configuration and topology of the network elements and the communication network may be obtained by the virtual test call application each and every time a use case logic (or even a use case logic command) is executed.
  • the virtual test call application my obtain all of the necessary static data relating to the configuration and topology of the network elements and the communication network once and cache the static information. Thereafter, when the use case logic is executed then the static information can be obtained form the cache. This method of caching the static information is most useful when several use case logics are executed one after the other.
  • the static information can be re-cached at a suitable time when the static information may have changed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne des procédés et un appareil pour mettre en œuvre des appels d'essais virtuels pour vérifier si un service peut être obtenu dans un réseau de communication. Les appels d'essais virtuels sont prédéfinis comme une logique de cas d'utilisation 209 qui comprennent au moins une commande de logique de cas d'utilisation qui représente une fonction réelle dans un réseau de communication. En fonction de l'une ou des deux parmi les données statiques relatives audit réseau de communication et les données dynamiques relatives audit réseau de communication, la fonctionnalité d'appel d'essais virtuels 201 peut déterminer si la logique de cas d'utilisation 209 sera réussie.
PCT/EP2008/068241 2008-12-23 2008-12-23 Appel d'essais virtuels Ceased WO2010072268A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/068241 WO2010072268A1 (fr) 2008-12-23 2008-12-23 Appel d'essais virtuels

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/068241 WO2010072268A1 (fr) 2008-12-23 2008-12-23 Appel d'essais virtuels

Publications (1)

Publication Number Publication Date
WO2010072268A1 true WO2010072268A1 (fr) 2010-07-01

Family

ID=40674159

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/068241 Ceased WO2010072268A1 (fr) 2008-12-23 2008-12-23 Appel d'essais virtuels

Country Status (1)

Country Link
WO (1) WO2010072268A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999018695A1 (fr) * 1997-10-07 1999-04-15 Attune Networks Ltd. Localisation des pannes et test des performances pour des reseaux de communication
WO2005094001A1 (fr) * 2004-03-23 2005-10-06 Telecom Italia S.P.A. Systeme et procede pour l'analyse du statut de qualite d'un reseau d'acces supportant des services de telecommunication en bande large
WO2006060491A2 (fr) * 2004-12-01 2006-06-08 Cisco Technology, Inc. Systeme et procedes de detection de defaillance d'un reseau

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999018695A1 (fr) * 1997-10-07 1999-04-15 Attune Networks Ltd. Localisation des pannes et test des performances pour des reseaux de communication
WO2005094001A1 (fr) * 2004-03-23 2005-10-06 Telecom Italia S.P.A. Systeme et procede pour l'analyse du statut de qualite d'un reseau d'acces supportant des services de telecommunication en bande large
WO2006060491A2 (fr) * 2004-12-01 2006-06-08 Cisco Technology, Inc. Systeme et procedes de detection de defaillance d'un reseau

Similar Documents

Publication Publication Date Title
CN103354633B (zh) 基于信令数据挖掘分析的特定移动用户粗定位系统及方法
WO2022095523A1 (fr) Procédé, appareil et système de gestion de modèle d'apprentissage automatique
CN113055421B (zh) 一种服务网格治理方法及系统
CA2272609A1 (fr) Systeme de gestion des pannes de logiciels
JP2009532769A (ja) Ｓｍｓｓｐａｍフィルタリングを実装する方法および装置
US20120079024A1 (en) Method and management agent for event notifications correlation
CN106612199A (zh) 一种网络监控数据收集与分析系统及方法
CN117546442A (zh) 标识利用多个活动管理功能（admf）的合法拦截部署中的admf
CN102769547A (zh) 一种信令数据提供系统和方法
CN102045182B (zh) 一种业务故障确定方法、装置和系统
CN113329338B (zh) 一种用户流动行为处理方法、装置、电子设备及存储介质
CN110166528A (zh) 防止节点变更通知丢失的方法、装置和计算机设备
KR100194763B1 (ko) 개인통신서비스 가입자정보처리장치 및 그 방법
WO2010072268A1 (fr) Appel d'essais virtuels
US5966713A (en) Method for determining the contents of a restoration log
CN101242298B (zh) 一种网管性能管理的接口方法及系统
CN104104555B (zh) 监控方法、系统、控制端及执行端
CN114090293B (zh) 一种服务提供方法及电子设备
CN105763380A (zh) 一种网管数据获取方法和装置
CN102547565A (zh) 一种移动用户位置管理和移动网络基于位置分析的系统
CN102474811A (zh) 用于管理移动设备漫游的方法和系统
KR100807893B1 (ko) 서비스 데이터 네트워크 관리 시스템 및 그 운용 방법
EP4443836B1 (fr) Serveur d'activation de données d'application, programme et support lisible par ordinateur
KR960001047B1 (ko) 신호망관리시스템의 시험망 형상 생성 및 성능분석 시험방법
KR100875912B1 (ko) 개방형 환경에서의 네트워크 이벤트들을 처리하는 통신망이벤트 처리 장치 및 그 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08875536

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08875536

Country of ref document: EP

Kind code of ref document: A1