A METHOD, A SYSTEM AND A COMPUTER PROGRAM PRODUCT FOR TROUBLESHOOTING

Field of the Invention

This invention relates to a method for service troubleshooting in a network and to a system for service troubleshooting in a network. In addition the invention relates to a computer program product. The invention also relates to a method for troubleshooting in a customer service and to a system for troubleshooting.

Background of the Invention

It is expected that a mobile network and a fixed broadband network will converge. This means that a user of a multi-access terminal can be in contact with more than one network at the same time. Such multiaccess terminals have been introduced to the market. Conventionally the user has had to switch the network e.g. from GSM (Global System for Mobile Communications) to UMTS (Universal Mobile Telecommunications System). Due to the convergence it is possible to provide new and to improve the existing end-to-end services. In addition operator costs can be reduced, because co-operation (the traditional way) between the fixed broadband network and the mobile network can be minimized. Co-operation means that, for example, VoIP (Voice over Internet Protocol) services will be possible with the mobile terminal.

Generally, it is possible to troubleshoot the communication network, e.g. its condition and functionality, because problems occurring in the communication network will remain and be stored in those network components where the problem has occurred. Therefore, the operator can track the problem and eliminate the cause for it. According to the applicant's knowledge, there is no built-in system for controlling traffic in a fixed IP (Internet Protocol) network. However, if problems need to be tracked in the IP network, special polling methods can be used, or network state can be queried. In the case of end-to-end services it is

necessary to pay attention to the functionality and quality between the ends in order to solve whether the complete end-to-end is not working or whether only part of it is not working. End-to-end testing is based on the emulation of the behaviour of a user's terminal on those interfaces where the terminal is connected to the network. It can be realized that testing from a operator's point of view is different than testing from a client's point of view. This is a result of asymmetric networks, such as ADSL (Asymmetric Digital Subscriber Line), where data and services are transmitted to different directions with different rates.

If speech is transmitted in the data network for corporate systems, it is possible to test and search problems by means of separate control systems. In practice the testing process is implemented in such a manner that a separate testing device is taken to corporate premises, by means of which a test is run and causes to problems are searched for. Obviously this kind of testing is expensive, and thus more suitable for corporate systems than for private customers. Because the number of private customers is large, it would become more difficult to charge such testing from the private customers. A typical problem that occurs in the traditional testing relates to firewall settings. Because firewall settings are not symmetrical, traffic is allowed to one direction, but not to another.

Currently there are numerous methods for testing VoIP quality from a personal computer's point of view. This kind of a VoIP quality testing is active testing, which precisely simulate user-level transactions. The testing is carried out to a certain destination that is selected from menu options by the user, and thus the location is not necessarily the actual target for the communication. It can thus be realized that this kind of a method gives only an assumption of the destination, and therefore the testing will be implemented not to the actual target, but to the selected target.

Therefore, what is needed is a solution for troubleshooting end-to-end services from an exact location to another exact location and by taking into account actual customer data.

Summary of the Invention

The current invention is addressed to such a need, and provides a self- management testing solution for fixed network troubleshooting, whereby the customer can diagnose the problem either together with calling customer service (so-called helpdesk) or even without calling customer service. According to that, the testing will be implemented from the customer's side. This solution is achieved by a method, a system and a computer program product.

The method for service troubleshooting in a network is characterized in claim 1. The system for service troubleshooting in a network is characterized in claim 17. The computer program product is characterized in claim 32. The method for troubleshooting in a customer service is characterized in claim 33. The system for troubleshooting is characterized in claim 39.

In the invention the terminal is used as a probe, which makes it possible only to troubleshoot e.g. network and leave possible configuration problems of the user's personal computer out from the troubleshooting. The software pretends to be a certain service, whereby a similar troubleshooting is activated in the software. The similar troubleshooting means that network points, i.e. predefined activation points, relating to said certain problem are the target for the troubleshooting. When the troubleshooting is carried out, the terminal is informed of a result of the troubleshooting. In addition to the results, also instructions on how to proceed with the result can be informed to the terminal. In some situations, the troubleshooting result may be transmitted to a server from the terminal.

The troubleshooting software can be downloaded to the terminal along with service-related parameters that can be delivered to the terminal via a mobile network, or the troubleshooting software can be permanently installed in the terminal. The terminal is connected to a multi-access device through which the troubleshooting is executed.

The troubleshooting software can be executed by a launching command from a user, or from a WWW (World Wide Web) or WAP (Wireless Application Protocol) page, or from the server.

In the invention other troubleshooting can also be carried out along with the terminal by a monitoring probe.

By means of the invention the work load at the customer service can be reduced, because simple problems can be corrected by the customer. However, the current invention is also helpful for difficult problems, because when the customer connects to the customer service, the troubleshooting has already been done or started. Therefore the customer service can only analyse the results or utilize them further in more detailed testing.

The testing is user-friendly and does not require special education for carrying it out. This invention provides good value to the customer service when the self-management testing is processed beside the customer service. It will be appreciated that a completely automatic solution would not necessarily provide all the benefit, because some problems can be solved only by the customer service.

Description of the Drawings

The current invention is illustrated by means of the following drawings, where

Figure 1 illustrates an example of the system configuration according to the present invention, and

Figure 2 illustrates another example of the system configuration according to the present invention.

Detailed Description of the Invention

The purpose of the present invention is to make it possible to implement service troubleshooting with a customer's terminal. This means that network events, such as fixed services can be tested by means of the terminal using said services. In the present description the term "customer" relates to a subscriber of the operator network, a user of the terminal and to a customer of the service. Therefore the term customer should be considered as broad as possible. The term "service" relates to a service, a part of the service or a network quality, and the service is subscribed by the customer. A "terminal" in this context is a multi-access terminal providing at least both mobile and home network (LAN) connectivity. Multi-access means that the terminal is capable of simultaneous voice/packet communications. For example, the customer can communicate e.g. by voice while using packet transmission. The service troubleshooting performs e.g. active (i.e. generates test traffic) availability and performance tests relating to certain services and networks. Examples of services and networks are e.g. such as IP (Internet Protocol) connectivity, DNS (Domain Name System), DHCP (Dynamic Host Configuration Protocol), Radius, email, WWW (World Wide Web), VoIP (Voice Over IP) and UMA (Unlicensed Mobile Access). What is to be tested is determined according to what has been sold to the customer and where the problem has occurred. For example, if the customer has ordered an email service and VoIP service, the testing can be targeted to them. Similarly, the testing can be targeted to such networks to which the customer is subscribed. For these tests the only information that is needed is information on the services the customer is capable of using. If the problem in question relates to an operating system of the terminal or to a terminal's model, then information on which terminal is used and what is the operating system in the terminal is needed for testing. In other cases the information on the terminal is unnecessary, and therefore almost any multi-access terminal can utilize the current invention.

At the time the customer notices a problem occurring e.g. with the terminal, with the fixed network connection or with the service, the customer may form a connection to the customer service via a mobile network. The customer may have troubleshooting software installed

already or the troubleshooting software can be installed at this point. The troubleshooting software is deployed at the terminal in order to carry out the troubleshooting. The software can be a permanently installed client, a network downloadable Java applet, a software component, a plugin, a packet or the like. The customer is identified at the customer service, whereby the customer service can automatically see what services the customer can use, and what kind of service- related parameters should be used in the troubleshooting software. The customer can be identified by SIM information or by other means, for example, if a fixed network is used.

In order to inform of a problem to the customer service the customer can use a graphical user interface relating to the troubleshooting software and make selections in a menu presented in the interface. The view of the interface can vary dynamically according to the customer's characteristics. For example, if the customer selects a "Network problem" from the menu, then the varying options could concern e.g. Internet-based problems or problems relating to forming a connection (e.g. is IP-address received) or WLAN. The user interface can also be used for activating the troubleshooting process and for reporting results.

The service-related parameters for what will be tested and how the troubleshooting process should be carried out are delivered to the troubleshooting software by the central server, e.g. customer service. The service- related parameters can be considered as test instructions relating to a certain problem of a certain service according to which the troubleshooting can take place. The communication between the terminal and the central server may take place via mobile data services, e.g. such as GPRS, GSM/3G circuit switched (cs) data, SMS (Short Message Service) or IM (Instant Message). In the case of mobile packet data or circuit switch data (GPRS, GSM/3G cs data) the terminal needs to open the data connection to the central server. In the messaging situation (SMS, IM) the instructions can be given directly to the terminal or the central service may ask the terminal to open the mobile data connection to the central server. For security reasons it

would be better if the terminal did not communicate with the central server at the same time as the terminal is performing the troubleshooting. Therefore, after the terminal has the service related parameters, the connection to the central server is terminated and the terminal connects to the home network. When the troubleshooting has been performed, the terminal terminates the connection to the home network and reconnects to the central server in order to report the measurement results.

The software can be used either as a customer activated tool or an operator's helpdesk activated remote management tool. In both cases the testing is about self-management troubleshooting relating to the fact that it is implemented from the customer's side. There are different possibilities to start the troubleshooting when the troubleshooting software has already been installed to the terminal. One possibility for the customer is to give a launching command to the troubleshooting software by using the software's embedded user interface, e.g. graphical or text-based, after which the troubleshooting software connects to the central server in order to get the service-related parameters as described above. If a downloadable troubleshooting software client, a Java applet, a software component, a plugin, a packet or the like is used, the customer must download that first. When the troubleshooting activation is done by the customer, the service operator may require acceptance from the customer.

Another possibility for the customer is to activate the troubleshooting process by visiting a Web or WAP launching page, which then starts the communication between the terminal and the central server as described above. This communication transmits a launching command to the terminal and automatically activates the troubleshooting software at the customer's terminal if the customer has not started it manually. If a downloadable troubleshooting software client or a Java applet is used, the first step is to push it to the terminal or ask the customer to download it.

Yet another possibility for the customer is to visiting a Web or WAP launching page and to let the service operator's representative activate the troubleshooting process, which starts the communication between the terminal and the central server as described above. This communication may require the customer's acceptance especially if the aim is to launch the troubleshooting software automatically at the customer's terminal. When downloadable troubleshooting software is used, the first step is to push that to the terminal or to ask the customer to download it.

If the problem occurred is not in the customer's terminal but more likely in the IP-network, the customer service may ask for the IP-address in question, by means of which it can allow testing for a limited time from the terminal to said IP-address. The helpdesk may open activation points in the network, after which it can modify and monitor them and check log files. If the problem is in the access to a certain server, accesses to other servers can be tested after firewalls are closed.

The troubleshooting software generates tests by using the service- related parameters, through the same networks and connections as the customer normally uses and aims to find out whether the services and networks are working correctly. It will be appreciated that by using the service-related parameters, the software actually emulates a certain service and routes, parameters, functions and network protocols used by the service, or by the terminal. The troubleshooting may take place through the home network that is connected to a multi-access device, CPE (Customer Premise Equipment, e.g. ADSL router). This requires that the multi-access terminal supports fixed or wireless LAN technology (e.g. WLAN) and is capable of joining the LAN.

The troubleshooting results are informed to the customer by the user interface. If the solution to the problem is straightforward and the customer is expected to take the necessary actions to correct it, the guidance to the customer can be given via the user interface. However, if the problem is more complicated, and it would be difficult for the customer to correct it, the instructions to the customer can include a

request to call the customer service. In this case, the provided customer service number can be different than the publicly shared customer service number. By calling such a number, the customer service already knows whether the customer has made the tests already. If so, all the requested information (i.e. results) can be provided to the customer service computer, and the customer can be helped more efficiently. It is also possible to ask e.g. a code number from the customer, whereby the customer service will be confident that the preliminary troubleshooting has been done. It is understood that because the troubleshooting result is sent to the customer service, the customer service can act more quickly and effectively for solving the problem.

Figure 1 illustrates an example of a system comprising a multi-access terminal 100 and a customer service's central server 120. The terminal 100 may comprise troubleshooting software or the terminal 100 can be capable of fetching one from the central server 120. When testing is needed, the customer can launch (20) the software manually in the terminal 100. It is also possible that the customer service (2) launches (20) the troubleshooting software by SMS, IM or asks the customer to activate it and possibly gives a one-time activation code. For security reasons the connection to the server is terminated when the troubleshooting software is launched. The IP is transmitted to the server by means of other connections, such as SMS or IP connection. When the troubleshooting software is launched, it retrieves (21 ) service-related parameters and sequence description from the central server 120 by opening a mobile data connection to the server 120. It is also possible that the terminal 100 receives e.g. SMS or IM which contains the necessary service-related parameters for testing.

When the parameters are received, the terminal terminates the possible connection to the central server 120 and retrieves (15) an IP address from a multi-access device's (1 10) DHCP, which IP address is valid as long as the testing will last. After that the terminal 100 connects to the customer's home network (1 ). The terminal 100 and the multi-access device 1 10 may have a wireless connection (10), such

as Bluetooth, Wireless USB, WLAN etc. The troubleshooting (30) is carried out through the customer's home network (1 ) to activation points (310, 320, 410, 510, 520, 610, 620, 630), such as network resources, test probes and the customer services in networks 3, 4, 5, 6, such as UMTS/GSM, Internet, corporate intranet and operator backbone/access network. When the troubleshooting has been carried out, the results are received in the terminal 100. The connection to the customer service 2 is formed again, and the results are sent (25) to central server 120 via e.g. SMS, IM or mobile data. Due to the results the terminal 100 receives instructions on what should be done to correct the problem.

Figure 2 illustrates another example, which is very similar to the one presented in figure 1. However, in figure 2 the troubleshooting procedure is collaborative. This means that the customer service 2 also comprises a monitoring probe 125 that is capable of performing (40) troubleshooting as well. The troubleshooting (40) performed by the monitoring probe 125 is carried out from the network's perspective, and therefore the testing will be expanded. For example, at the same time as the terminal 100 is running the troubleshooting (30), the monitoring probe 125 also runs another troubleshooting (40). By doing this the results from the monitoring probe 125 and the results from the terminal 100 can be correlated, which further improves the central server accuracy and efficiency of the measurement and troubleshooting.

Compared to conventional solutions, instead of sending an actual mechanic to a customer's home to solve the problem, the current solution where the troubleshooting procedure is performed automatically and is started by the customer, will be a great benefit for operators both economically and for helping the work load of customer service and mechanics.

The foregoing detailed description is provided for clarity of understanding only, and should not be interpreted as restrictive to the invention presented in the claims hereinbelow.