Title of Invention	A METHOD FOR EMULATING THE TWO-WAY INFORMATION FLOW OF A REAL APPLICATION AND A SYSTEM FOR THE SAME
Abstract	The invention relates to a method for emulating the two-way information flow of a real application in a system, which comprises a first network element (101) and a second network element (102), as well as a packet network (103) between said first network element and said second network element, which method comprises: transmitting a set of packets (300) from the first network element through the packet network to the second network element; receiving at least part of the transmitted packets at the second network element; transmitting the received packets from the second network element through the packet network back to the first network element in response to the receiving of the packets at the second network element, characterised in that the method comprises transmitting a packet arrived at the second network element back to the first network element only after a delay from the receiving of the packet at the second network element.

Title of Invention

A METHOD FOR EMULATING THE TWO-WAY INFORMATION FLOW OF A REAL APPLICATION AND A SYSTEM FOR THE SAME

Abstract

The invention relates to a method for emulating the two-way information flow of a real application in a system, which comprises a first network element (101) and a second network element (102), as well as a packet network (103) between said first network element and said second network element, which method comprises: transmitting a set of packets (300) from the first network element through the packet network to the second network element; receiving at least part of the transmitted packets at the second network element; transmitting the received packets from the second network element through the packet network back to the first network element in response to the receiving of the packets at the second network element, characterised in that the method comprises transmitting a packet arrived at the second network element back to the first network element only after a delay from the receiving of the packet at the second network element.

Full Text	Emulating of Information Flow The present invention relates to the emulating of the two-way information flow of a real application. Particularly, but not necessarily, the invention relates to the emulating of the information flow of a VoIP (Voice over Internet Protocol) call for determining the Quality of Service (QoS) at a VoIP application level. Traditionally, when calling by telephone speech has been transferred in circuit-switched networks, such as in a Public Switched Telephone Network (PSTN). When calling by telephone in a digital circuit-switched network, a permanent connection of 64 kbps (kilo bits per second) is set up for each call. The standard band of the connection, 64 kbps, is due to the bit rate required in the sampling of analog speech when using 8-bit Pulse Code Modulation (PCM) at a sampling frequency of 8 kHz, which procedure enables the transmitting of analog speech having a frequency of 300 to 3400 Hz in a digital format. The digital telephone network described above that is presently in common use is, however, very ineffective and thus consumes a lot of network resources. In the telephone network, the band for a connection is also reserved when the connection is not used actively, i.e. neither party of the connection is transferring information, such as speech or data, along the connection. The kind of use of a static band consumes a lot of data transmission resources, and as a result of this additional capacity must be invested in as the number of users increases. The type of ineffectiveness described above causes problems especially in calls between continents, where increasing the data transmission capacity is not as easy as in other cases. The problem is also partly manifest in call prices; expensive investments in capacity must be covered by high user charges. To compensate and supplement calls that use a static band reservation in a telephone network, so-called VoIP calls, i.e. IP calls have been started to be marketed. Typically, the information transmitted in an IP call, such as speech, voice and/or video, is first converted from an analog format into a digital format, then compressed and converted into IP packets that are conveyed over an IP-based packet-switched network, such as the Internet network, sharing the band with other IP traffic. In IP calls, a band can be used in a considerably more effective way than in calls that reserve a static band, which is also shown in call prices. In addition, also new more effective coding schemes can be used, such as e.g. G.723.1 coding. The time of arrival of transmitted IP packets to a receiver is not known before the packets arrive. And because IP routes the information flow packet by packet the time of propagation of packets from a sender to a receiver may vary greatly and the order of the packets may change. Furthermore, packets may be lost, for example, as a result of the overflows of incoming data that take place in the buffers of routers. By using a reliable protocol over IP, for example, packet losses can be identified automatically at a protocol level and the lost packets can be retransmitted. One such protocol is TCP (Transmission Control Protocol). However, the retransmissions in question would cause additional varying delay in the transmission of information over the IP network. And since several applications used in repeating speech and/or picture transferred in real time do not function flawlessly if, for example, too much delay occurs in the transmission of information, TCP is not well suitable for use as a protocol to be used over IP in IP calls. Therefore, UDP (User Datagram Protocol), where there are no retransmissions, is normally used in IP calls. Instead, in a call setup, the use of TCP is recommendable so that the call setup would take place as reliably as possible. For example, just for the reason that the applications used in repeating realtime information transmitted over an IP network have high realtime requirements in order to function flawlessly, at least some kind of arrangement is needed to guarantee the desired Quality of Service (QoS) for the IP call in question. IP as such does not provide QoS support in a form that it would provide a guaranteed Quality of Service. However, several different techniques exist with which a guaranteed QoS can be provided in an IP network. These are, among others, DiffServ (Differentiated Services) and IntServ (Integrated Services) techniques. Irrespective of which QoS technique is used, it is important that the QoS can be measured in order to find out whether it is really possible to provide a guaranteed QoS for each IP call. Usually, several QoS parameters are required to describe a QoS. Thus, it is appropriate to measure values for a set of different QoS parameters, which in connection with VoIP are, for example, the following: end-to-end delay, end-to-end delay jitter, packet losses and packet loss correlation. Of these, end-to-end delay means the time that it takes for an IP packet to pass through an IP network from a sender to a receiver. End-to-end delay can also be measured as a round trip measurement, whereupon the time that it takes for an IP packet to pass from a sender to a receiver and back is measured. End-to-end jitter can be denoted, for example, as a standard deviation or variance. Packet losses tell how many of the transmitted IP packets fail to be received on the receiving side, i.e. how many IP packets are lost on the way. As for the system performance, it is highly significant whether IP packets disappear or are lost one here and another there (no packet loss correlation) or whether several successive IP packets are lost (high packet loss correlation). Figure 1 shows a principle of one QoS measurement according to prior art. There a stream of IP packets is transmitted from a first host 101 through an IP network 103 to a second host. Before transmitting, the first host 101 adds a first information to each IP packet to be transmitted. The stream of IP packets transmitted by the first host 101 is received at the second host 102, which adds a second information to the IP packets and returns them through the IP network 103 back to the first host 101, which adds a third information to the received IP packets. Figure 2 illustrates the structure of an IP packet, the use of which is well known in the QoS measurement arrangement illustrated in Figure 1. An IP packet 200 comprises various types of fields for storing the information added by hosts to the IP packet. For example, in fields 201 and 202, the first host 101 stores just before transmitting the IP packet as said first information a time stamp data TST and a packet sequence number data SEQT respectively. In fields 203 and 204, the second host 102 stores as said second information on receiving the IP packet a time stamp data TS2and a packet sequence number data SEQ2 respectively. After receiving the IP packet, the second host 102 returns the IP packet immediately back to the first host 101 which stores, in a field 205, as said third information a time stamp data TS3 on receiving the IP packet. Now, of the QoS parameters, e.g. end-to-end delay drt can be determined by equation drt=TS3-TS1 In addition to the fields 201 - 205, the IP packet 200 in Figure 2 comprises a dummy length 206. The dummy length 206 is a data portion of a specific length with which the length of the IP packet can be adapted to the size of the packets of a realistic codec, such as G.711. If the IP packets 200 are yet transmitted as such a typically uniform stream of IP packets as is formed by a realistic codec, a real IP call and its QoS measurements can be emulated by the arrangement presented above. However, the arrangemen; according to prior art described above has its problems. Let us assume ;hat a stream of IP packets 200 is sent from the first host 101 through the IP network 103 to the second host 102 and that the transmitting of the IP packets from the first host to the second takes place uniformly. In an ideal case, the time of transmission of all the IP packets (end-to-end delay) from the first host to the second is the same, whereupon the IP packets sent from the first host would also arrive at the second host uniformly. However, in reality, the situation is typically such that, for example, due to a varying IP network load IP packets do not arrive at the second host uniformly but burstly. By this is meant that the stream of IP packets arriving at the second host comprises densities (clusters of IP packets) and spacings (there is an exceptionally long pause between IP packets) instead of a steady stream. When the second host now returns each IP packet it has received back to the first host, the stream of returned IP packets is already on leaving the second host bursty and not uniform as it would be in the case of a realistic IP call. In this case, the QoS experienced by the bursty stream of IP packets returning from the second host to the first host is normally worse than the QoS experienced by the stream of IP packets transmitted uniformly from the first host to the second host. This asymmetry is not characteristic of a real IP call and it distorts the measuring of the values of QoS parameters. Furthermore, if IP packets sent by the first host are lost on their way to the second host, the stream of IP packets returned from the second host to the first has less IP packets than in the original stream of IP packets sent from the first host to the second. In this case, more additional spacings are automatically formed in the stream of IP packets returned from the second host to the first, which again increases asymmetry. Thus, the measurement arrangement according to prior art presented above is not suitable in the best possible way for the QoS measurements of an IP call. Now, a new solution has been invented, which is suitable for making QoS measurements of an IP call. According to a first aspect of the invention, there is implemented a method for emulating the two-way information flow of a real application in a system, which comprises a first network element and a second network element, as well as a packet network between said first network element and said second network element, which method comprises: transmitting a set of packets from the first network element through the packet network to the second network element; receiving at least part of the transmitted packets at the second network element; transmitting the received packets from the second network element through the packet network back to the first network element in response to the receiving of the packets at the second network element. It is characteristic of the method that it comprises: transmitting a packet arrived at the second network element back to the first network element only after a delay from the receiving of the packet at the second network element. According to a second aspect of the invention, there is implemented a system for emulating the two-way information flow of a real application, which system comprises a first network element and a second network element, as well as a packet network between said first network element and said second network element, which first network element comprises: means for transmitting a set of packets from the first network element through the packet network to the second network element, and the second network element comprises: means for receiving at least part of the transmitted packets at the second network element; means for transmitting the received packets from the second network element through the packet network back to the first network element in response to the receiving of the packets at the second network element. It is characteristic of the system that the second network element further comprises: means for transmitting a packet arrived at the second network element back to the first network element only after a delay from the receiving of the packet at the second network element. According to a third aspect of the invention, there is implemented a network element for emulating the two-way information flow of a real application in a system, which in addition to said network element comprises a specific first network element and a packet network between the network element and said first network element, which network element comprises: means receiving packets transmitted from said first network element through the packet network; means for transmitting the received packets through the packet network back to the first network element in response to the receiving of the packets at the network element. It is characteristic of the network element that the network element further comprises: means for transmitting a packet arrived at the network element back to the first network element only after a delay from the receiving of the packet at the network element. According to a fourth aspect of the invention, there is implemented a computer program product executable in a network element for emulating the information flow of a real application in a system, which in addition to said network element comprises a specific first network element and a packet network between the network element and said first network element, which computer program product comprises a program code: for receiving at the network element packets transmitted from the first network element through the packet network; for transmitting the received packets through the packet network back to the first network element in response to the receiving of the packets at the network element. It is characteristic of the computer program product that the computer program product comprises a program code: for transmitting a packet arrived at the network element back to the first network element only after a delay from the receiving of the packet at the network element. In a preferred embodiment of the invention, said network elements are computers, such as PCs (Personal Computer), workstation computers or network server computers, and said packets are communication packets, such as IP packets. The present invention enables better emulating of the two-way information flow of a real application, such as the information flow of an IP call, at an application level with uniform streams of IP packets and signalling than is known from prior art and thus, the performing of more reliable QoS measurements than the known solutions. The invention can be used, among other things, in network designing and for testing the performance of a network from the viewpoint of VoIP. By the term IP network is meant in this description besides networks based on IP, such as Internet and Intranet networks, also other similar packet networks, such as the X.25 network. By the IP call is meant a call where information, preferably speech, voice, video or multimedia, is transferred over this kind of network typically for implementing a realtime service. Thus, the invention can also be used for emulating a vi8eoconference. In the following, the invention will be described in detail by referring to the enclosed drawings, in which Figure 1 shows the principle of one QoS measurement according to prior art; Figure 2 shows the structure of an IP packet used in one QoS measurement according to prior art; Figure 3 illustrates the structure of an IP packet suitable for the implementation of one embodiment of the invention; Figure 4 shows an exemplary case with the help of which one embodiment of the invention is illustrated; Figure 5 is a diagram of a time domain illustrating the exemplary case shown in Figure 4; and Figure 6 illustrates hardware for implementing the invention. Figures 1 and 2 were already explained above in connection with the description of prior art. Next, a preferred embodiment of the invention will be explained where an IP call between a first host and a second host is emulated and QoS measurements are performed. Roughly, Figure 1 can also illustrate a measurement arrangement according to the invention. In a preferred embodiment of the invention, a first host 101 transmits through an IP network 103 to a second host 102 a similar uniform stream of IP packets as is formed by a realistic codec, such as G.711, where the size of the IP packets corresponds to the size of the packets formed by the real codec. The IP packets are preferably transmitted by using UDP over IP. Figure 3 illustrates the structure of an IP packet, which is used in the preferred embodiment of the invention. An IP packet 300 comprises various types of fields for storing the information added by the hosts to each IP packet at specific moments of time. In fields 301 and 302 of each IP packet, the first host 101 stores as first information just before transmitting each IP packet 300 a time stamp data TS-i and a packet sequence number data SEQ1 respectively. For example, when transmitting a first IP packet the first host stores as the time stamp data TSi of the IP packet in question the time of transmission of the IP packet in question and as the sequence number data SEQltthe number 1. Correspondingly, as the time stamp data TSi of a second IP packet the transmitting time of the second IP packet is stored and as the sequence number SEQ1tthe number 2 and so on. As the IP packets of the stream of IP packets arrive at the second host 102, the second host stores in fields 303 and 304 of each IP packet as second information a time stamp data TS2 ano a packet sequence number data SEQ2 respectively. When the first IP packet (which is not necessarily the IP packet the first host > transmitted first) of the stream of IP packets arrives at the second host, the second host then stores the time of arrival of the IP packet in question at the second host as the time stamp data TS2 of the IP packet in question and the number 1 as the sequence number data SEQ2i. Correspondingly, the time of arrival of the second IP packet at the second host is stored as the time stamp data i TS2 of the IP packet in question and the number 2 as the sequence number SEQ2, and so on. However, according to the invention, the IP packets arrived at the second host are not returned immediately to the first host, but they (or their data) are guided into a buffer at the second host from where they are then transmitted in the order of arrival back to the first host as a similar uniform stream of IP packets as is formed by a realistic codec used in an IP call. In this way, asymmetry can be eliminated in the transmitting of IP packets better than in solutions known from prior art. When transmitting each buffered IP packet back to the first host, the second host stores in a field-305 of each IP packet as third information a time stamp data TS3. The transmitting time of each IP packet is stored as the time stamp data TS3. As the IP packets of the stream of IP packets returned from the second host to the first host arrive at the first host, the first host stores in a field 306 of each IP packet as fourth information a time stamp data TS4. The time of arrival of each IP packet at the first host is stored as the time stamp data TS4. Preferably, for indicating the sequence in which the IP packets return to the first host a new sequence number indicator (e.g. SEQ3) is not required if the received IP packets (or the data comprised by them) are stored in the same sequence as they arrived at the first host. Naturally, using the sequence number indicator SEQ3 in connection with the invention is possible however. In addition to the fields 301 - 306, the IP packet 300 in Figure 3 comprises a dummy length 307. The dummy length 307 is a data portion of a specific length , which does not necessarily have any significance other than that with it the length of an IP packet can be adapted to the size of the packets of a realistic codec, such as G.711. In addition to the fields shown in Figure 3, the IP packet 300 typically comprises IP and UDP headers, among other things, for the address information and port numbers of a sender and a receiver. The content of the fields 301 - 307 can be called by the term payload. Now, of the QoS parameters, a round trip end-to-end delay drt can be determined by the equation dn.new = TS4 - TS1 - (TS3 - TS2). If the clocks of the first and second hosts have been synchronised, one-way end-to-end delays can be calculated by using the equations d0W\|1 = TSi'- TSj (the trip from the second host to the first) and d0Wt2 = TS4 - TS3 (the return trip from the second host to the first). In synchronising the hosts, e.g. GPS (Global Positioning System) can be used. Material for calculating the end-to-end delay jitter is obtained, for example, by calculating the differences between the time stamps TS2 of successive IP packets arrived at the second host. On the basis of the differences, for example, the standard deviation and/or variance of the end-to-end delay jitter (from the first host to the second host) can then be calculated. Packet losses can be found out when the number of transmitted IP packets is known. In this case, when the stream of IP packets has gone the round trip between the first and second hosts, for example, the number of packets lost during the first part can be found out by subtracting the number of IP packets arrived at the second host from the number of packets transmitted. Packet loss correlation (here from the first host to the second host) can be examined by studying the sequence numbers SEQT of the IP packets received at the second host and by seeing which sequence numbers are missing. Next, the implementation of the preferred embodiment of the invention will be presented in more detail with the help of an exemplary case by referring to Figures 4 and 5 of which Figure 4 shows the basic arrangement in the exemplary case and Figure 5 is the diagram of a time domain for illustrating the exemplary case. In Figure 5, the left time axis shows the time according to the clock of the first host and the right time axis shows the time according to the clock of the second host. The clocks of the first and second hosts can be synchronised with each other. Let us assume that the number of IP packets to be transmitted N = 4. In transmitting the IP packets, the transmitting interval of IP packets formed by a realistic codec, be it Atti, is emulated. Prior to the QoS measurements, a message is sent from the first host to the second host, wherein the values of the parameters N, Atti and the buffer delay Atbuf are indicated to the second host. It must be noted here that although for reasons of simplicity in this exemplary case the number of : IP packets transmitted N = 4, in reality the number of IP packets transmitted can be considerably higher, e.g. several hundreds or thousands. Now, from the first host 101 to the second host 102 through the IP network 103 a stream of IP packets is transmitted where, in a first IP packet (packet A), the sequence number SEQt = 1 and the time stamp TST are stored just before the transmitting of the IP packet in question at the moment of time tlf in a second IP packet (packet B), the sequence number SEQ1 = 2 and the time stamp TSi are stored at the moment of time t2, in a third IP packet (packet C), the sequence number SEQT = 3 and the time stamp TSi are stored at the moment of time t3, and in a fourth IP packet (packet D), the sequence number SEQT = 4 and the time stamp TST are stored at the moment of time t4. The IP packets are transmitted at intervals of Atti, whereupon t2 - U =Atlit t3 -t2 =Atti and t4 -13 =Atti. Said moments of time t1( t2, t3 and U are according to the clock of the first host. After getting the message from the first host, in which message the number of the IP packets transmitted N is indicated to be four, the second host stores in a specific (transmitting) buffer four IP packets the sequence numbers of which are SEQ2 = -1 (the first IP packet to be transmitted from the buffer (packet E)), SEQ2 = -2 (the second packet (packet F)), SEQ2 = -3 (the third packet (packet G)), SEQ2 = -4 (the fourth packet (packet H)). After receiving, at the moment of time t5, the first of the IP packets transmitted by the first host, which here is the IP packet (packet A) that was also transmitted first (this is not always the case, e.g. if the first IP packet is lost on the way), the second host stores in the IP packet in question (packet A) the time stamp TS2 and stores as the sequence number SEQ2 = 1. After this, the second host copies the time stamp and sequence number data (TSi, SEQT = 1, TS2 and SEQ2 = 1) of the IP packet in question (packet A) in the IP packet (packet E) that is in the buffer the first in turn to be transmitted whereupon, among other things, in the IP packet that is in the buffer the first in turn to be transmitted, the sequence number (packet E) SEQ2 = -1 is substituted by the number 1. The packet E is now transmitted from the second host to the first host after the buffer delay AtbUf, at the moment of time tn = t5 + Atbuf. Just before transmitting, the second host stores, in the packet E, the time stamp TS3. This takes place approximately at the moment of time t^. When the stream of IP packets to be returned has now begun, the other three IP packets (packets F, G and H) waiting to be transmitted in the buffer of the second host at intervals of Atti at the moments of time t12 (packet F), t13 (packet G), and t14 (packet H), whereupon if for the packets E, F, G and H index numbers j = 1, 2, 3, 4 respectively are used, the transmitting time t^ of each packet according to the clock of the second host is obtained from the equation t1( = t5 + Atbuf + (j - 1) Atti. Correspondingly, when receiving some other (than the packet A described above) IP packet belonging to a stream of IP packets sent from the first host to the second host, the second host stores in the received packet the time stamp TS2 and the sequence number SEQ2i after which the second host copies the data of the received IP packet in such an IP packet in the transmitting buffer of the second host that is next in turn to be transmitted, wherein the data of some arrived IP packet has not yet been copied. Before transmitting each IP packet, the second host yet stores in each packet to be transmitted the time stamp TS3. Thus, in the situation illustrated by Figures 4 and 5, after receiving the packet B the second host stores therein the time stamp TS2 at the moment of time t6 and the sequence number SEQ2 = 2, because the packet B is the second IP packet that arrives at the second host. The data of the packet B are copied in the packet F waiting to be transmitted in the buffer whereupon, among other things, the sequence number of the packet F SEQ2= -2 is substituted by the number 2. The packet F is transmitted at the moment of time t12. Just before transmitting the time stamp TS3 is stored in the packet F, Next, a situation where a packet loss takes place will be examined in the exemplary case shown in Figures 4 and 5. Let us assume that the packet C disappears and fails to arrive at the second host. Because the buffer delay Atbuf in this case is so long that the packet (packet D) transmitted next nevertheless manages to arrive at the second host at the moment of time t8, which is before the transmitting time of the packet G t13 = t5 + Atbuf + 2 Atti (the packet G is the packet wherein the data of the packet C should be copied for return transmission), instead of the lost packet C the data of the packet D (TS1f SEQ1 = 4, TS2 and SEQ2 = 3) are copied in the packet G whereupon, among other things, the sequence number of the packet G SEQ2 = -3 is substituted by the number 3. The packet G is transmitted at the moment of time t13. The time stamp TS3 is stored in the packet G just before transmitting. Because the packet C failed to arrive at the second host, there is no such IP packet arrived at the second host from which data would not already have been copied in some packet, whereupon there is nothing to copy in the packet H. In order that a uniform stream of IP packets could be maintained, the packet H is nevertheless transmitted as a so-called dummy packet (filling packet) at the moment of time of transmission t14, although it does not now comprise values based on real time stamp and sequence number data for TS1( SEQ-t and TS2. Before transmitting the time stamp TS3 is stored in the packet H. Since a new sequence number SEQ2 was not copied in the packet H either, the original negative sequence number SEQ2 = -4 remains as the sequence number of the packet H. When the packets E, F, G and H arrive at the first host at the moments of time t15l t16, t17 and t18 respectively, the first host stores therein the time stamps TS4. For the QoS parameters, values can now be determined as was already described above. If the sequence number of some received IP packet SEQ2 is negative, the first host will identify it as a dummy packet, whereupon it does not take into account the information possibly found in the fields 301 (TSj), 302 (SEQ}) and/or 303 (TS2) of the dummy packet, because this information is not based on real time stamp or sequence number data. The existence of dummy packets in the returned steam of IP packets normally means that at least one of the IP packets originally transmitted from the first host to the second has failed to arrive at the second host or has arrived there too late. In the invention, however, error situations like this have been taken into consideration in the manner presented above (e.g. by the use of dummy packets), and the emulating of a realistic IP call and the QoS measurements will succeed even if packet losses occured. In an IP call, where realtime speech is transferred, there normally occur talkspurts and silent periods (pauses). This is due to the fact that when one party of the IP call speaks, the counter party normally is silent. For some VoIP terminals (wireless terminal, telephones), VAD (Voice Activity Detection) detectors have been developed, which operate so that when the level of a speech signal coming into the VAD detector falls below a specific limit (speaker is silent), IP packets will no longer be transmitted to the receiving end. In this case, data transmission band is saved. Next, the description of the invention will be supplemented by presenting how for performing QoS measurements an IP call is emulated according to the invention, the parties of which have a VAD function in their VoIP terminals. IP packets are now transmitted from the first host to the second host still at intervals of Atti, but when an amount of Nts IP packets have been transmitted, a pause is made in the transmitting of IP packets that will last for a period of NspAtti. After this, a new value is allotted for N^ and IP packets are transmitted for a period of NtsAttj. Then, a new value is allotted for Nsp and a pause is again made in the transmitting of IP packets for a period of NspAtti and so on. The figures Nts and Nsp are allotted from random distribution functions P(Nts) and P(Nsp) respectively, of which P(Nts) emulates the distribution of the lengths of talkspurts and P(Nsp) the distribution of the lengths of silent periods in a real IP call. The material for forming the distributions P(Nts) and P(Nsp) has been obtained, for example, by measuring lengths of talkspurts and pauses in real IP calls. In practice, the values of Nts and Nspcan be allotted for each talkspurt and silent period independently irrespective of each other in the first and second hosts. And since the information about the number N of the packets transmitted has already before the commencement of QoS measurements been delivered from the first host to the second, the total number of IP packets transmitted in both directions will tally. Alternatively, the values of Nts and Nspcan only be allotted in the first host, in which case the transmission of IP packets returned by the second host to the first host can be timed for a time period when IP packets are not arriving at the second host. So here the second host "is listening" whether IP packets are coming in and, if they are not, the second host starts the returning of the IP packets that are in the buffer, to the first host. In practice, "listening" can be implemented, for example, so that if IP packets have not arrived at the second host within a specific time (e.g. buffer delay Atbuf), the second host concludes that the first host has a silent period going, whereupon it starts the returning of IP packets to the first host. This description has above concentrated on describing the emulating of an IP call and the performing of the QoS measurements of the IP call. Because, in a real IP call, UDP is used where no retransmissions and acknowledgements are used, naturally these do not occur in the description of the invention either. However, in an IP call setup, a reliable protocol must be used, whereupon the retransmissions and acknowledgements of packets become of interest. Well-known VoIP signalling protocols are, among others, H.323 and SIP (Session Initiation Protocol). Signalling protocols enable in a call setup, for example, the fact that a VoIP terminal (first host) that is making an IP call and a VoIP terminal (second host) that answers the IP call can communicate to each other what type of codec each of the call party has in its use. For example, in H.323, most of the signalling used in a call setup takes place by using a reliable protocol, TCP. According to the invention, the setting up of an IP call is emulated by sending one or more IP packets from the first host to the second, depending on the signalling protocol to be emulated. Said IP packet used for emulating the call setup is otherwise similar to the IP packet 300 described above, but instead of the UDP-header it comprises a TCP header. Thus, in emulating a call setup, IP packets are preferably transmitted by using TCP over IP. A TCP header typically comprises, among other things, information that can be used in retransmitting lost IP packets. In emulating a call setup, always after receiving an IP packet transmitted by the first host the second host immediately transmits the same IP packet back to the first host. Now, the call setup time can be measured, which is the time that is consumed from the transmitting of the first IP packet to the receiving of the last IP packet at the first host. Alternatively, it is possible to transmit from the first host only one IP packet and wait for it to return from the second host. When the returned IP packet is received at the first host, the call setup time can now be approximated by multiplying the time between the transmitting of the IP packet and the receiving of the returned IP packet, e.g. by some number suitable for the purpose. In determining the call setup time, the time stamps TS2 and TS3 are not necessarily needed at all, because the IP packet is transmitted back immediately after arriving at the second host. The time between the transmitting of the IP packet and the receiving of the returned IP packet is obtained by subtracting the time stamp TST from the time stamp TS4. Naturally, the actual emulating of an IP call and the QoS measurements of the IP call will be commenced only after the emulating of signalling related to the call setup has been completed. Figure 6 shows hardware suitable for implementing the invention. The hardware comprises a first host 101 and a second host 102, as well as an IP network 103 between the hosts. The hosts can be, e.g. PCs that can be coupled to the IP network 103, for example, with a network access card (not shown in the figure). The first and second hosts comprise a unit MCU (Master Controlling Unit) that controls the host, as well as a memory MEM. The MCU can be, e.g. a microprocessor. Blocks 701-709 are functional blocks, wherein the MCU is arranged to carry out specific activities on the basis of a program stored in the MEM of the host. In the block 701, a time stamp data TS! is stored in the IP packets to be transmitted according to a clock CL of the first host just before transmitting, and a sequence number data SEQt. In the block 702, the IP packets are transmitted to the second host 102 through the IP network 103. In the block 705, the second host 102 receives the IP packets transmitted by the first host 101, wherein, in the block 706, a time stamp data TS2 is stored according to the clock CL of the system and a sequence number data SEQ2. In the block 707, the time stamp and sequence number data of the received IP packets TS-,, SEQ-,, TS2 and SEQ2 are copied in the IP packets waiting to be transmitted in a buffer. In the block 708, a time stamp data TS3 is stored in the IP packets to be transmitted to the first host according to the clock CL of the second host just before transmitting. In the block 709, the IP packets are transmitted to the first host 101 through the IP network 103. In the block 703, the first host receives the IP packets transmitted by the second host 102 wherein, in the block 704, a time stamp data TS4 is stored according to the clock CL of the first host. In practice, in the memory MEM of the hosts, there is a storage area wherein the MCU typically stores the content of each IP packet to be transmitted (time stamp and sequence number data). Thus, in transmitting an IP packet it is just this content of the storage area that is sent to the receiving end. By said storage area is meant, for example, the buffer in the second host mentioned above, wherein the IP packets are waiting to be transmitted to the first host. At the receiving end, the MCU stores the data of the received IP packets in its memory MEM, in a file, for a later analysis, such as for calculating the QoS parameters. Thus, the essential parts of the invention can be implemented programmably. The computer program products in question stored in the memories MEM of the hosts can be programmed in a programming language suitable for the purpose, such as C programming language. Because the invention provides means for emulating more accurately a realistic IP call at an application level with signalling and symmetric uniform IP packet streams than is known from solutions according to prior art, the invention enables the carrying out of the QoS measurements of an IP call more reliably than the known solutions. In the arrangement according to the invention, error situations of an IP network are also prepared for, whereupon with the arrangement according to the invention reliable QoS measurements can also be carried out when IP packets of an IP call are lost along the way or when they arrive at the receiving end too late. Although above, in the description of the invention, an arrangement was described which comprises two hosts and a packet network between them, there can also be more hosts. Thus, from a first host a stream of IP packets can be transmitted to two or more second hosts, which will all return the IP packets transmitted by the • first host. For example, in this way, it is possible to emulate an IP group call, which is made from one VoIP terminal to two or more VoIP terminals and carry out the QoS measurements. Furthermore, according to the invention, it is possible to emulate more than one IP call simultaneously or nonsimultaneously and thus, carry out the QoS measurements using several different pairs of hosts. This description presents the implementation and embodiments of the present invention, with the help of examples. For a person skilled in the it is apparent that the present invention is not restricted to details of the embodiments presented above, and that the invention can also be implemented in another form without deviating from the characteristics of the invention. The embodiments presented above should be considered illustrative, but not restricting. Thus, the possibilities of implementing and using the invention are only restricted by the enclosed claims. Consequently, the various options of implementing the invention as determined by the claims, including the equivalent implementations, also belong to the scope of the invention. Claims 1. A method for emulating the two-way information flow of a real application in a system, which comprises a first network element (101) and a second network element (102), as well as a packet network (103) between said first network element and said second network element, which method comprises: transmitting a set of packets (300) from the first network element through the packet network to the second network element; receiving at least part of the transmitted packets at the second network element; transmitting the received packets from the second network element through the packet network back to the first network element in response to the receiving of the packets at the second network element, characterised in that the method comprises transmitting a packet arrived at the second network element back to the first network element only after a delay from the receiving of the packet at the second network element. 2. A method according to claim 1, characterised in that the method comprises: transmitting said set of packets from the first network element through the packet network to the second network element as a uniform stream of packets; and in response to the receiving of the packets at the second network element, transmitting the received packets to the first network element as a uniform stream of packets emulating a real IP (Internet Protocol) call at an application level for determining the Quality of Service (QoS). 3. A method according to claim 1, characterised in that, in the method, the packets transmitted are IP packets that correspond in size to IP packets transmitted in a real IP call. 4. A method according to claim 1, characterised in that, in transmitting a packet (300), UDP (User Datagram Protocol) over IP is used. 5. A method according to claim 1, characterised in that said network elements (101, 102) are computers. 6. A method according to claim 1, characterised in that the method comprises for emulating a group call, transmitting from the first network element through the packet network a set of packets to a set of second network elements, which, in response to the receiving of the packets, return the packets they have received back to the first network element. 7. A method according to claim 1, characterised in that the method comprises using more than one network element pair, formed by the first and second network elements, for emulating more than one IP call. 8. A method according to,claim 1, characterised in that the method comprises emulating the call setup of an IP call by transmitting before transmitting said set of packets at least one packet from the first network element through the packet network to the second network element and by returning said at least one packet back to the first network element immediately after it has arrived at said second network element. 9. A method according to claim 8, characterised in that, in transmitting said at least one packet, TCP (Transmission Control Protocol) over IP is used. 10. A method according to claim 1, characterised in that when the second network element is about to return the packets it has received from the first network element in a case, where the second network element lacks the packet to be returned, a filling packet is transmitted from the second network element to the first network element for maintaining a uniform stream of packets. 11 .A method according to claim 1, characterised in that the method comprises transmitting first said set of packets from the first network element through the packet network to the second network element, after which a pause of a specific length (NspAtti) is made in the transmitting of the packets, after which pause a second set of packets is transmitted from the first network element through the packet network to the second network element for emulating the talkspurts and silence periods of an IP call. 12. A method according to claim 1, characterised in that the method comprises: storing in a packet to be transmitted from the first network element, in connection with the transmitting of the packet, a first time information (TSi) and a first sequence number data (SEQ0; storing in a packet received at the second network element, in connection with the receiving of the packet, a second time information (TS2) and a second sequence number data (SEQ2); storing at the second network element in a packet to be returned to the first network element, in connection with the return transmission of the packet, a third time information (TS3); storing at the first network element in a packet returned to the first network element, in connection with the receiving of the packet, a fourth time information (TS4); determining on the basis of said time information (TST - TS4) and sequence number data (SEQ-j - SEQ4) values for a set of parameters describing the Quality of Service for determining the Quality of Service (QoS). 13. A system for emulating the two-way information flow of a real application, which system comprises a first network element (101) and a second network element (102), as well as a packet network (103) between said first network element and said second network element, which first network element (101) comprises: means (MCU, MEM, 701, 702, CL) for transmitting a set of packets (300) from the first network element (101) through the p'acket network (103) to the second network element (102), and the second network element comprises: means (MCU, MEM, 705, 706, CL) for receiving at least part of the transmitted packets (300) at the second network element (102); means (MCU, MEM, 707 - 709, CL) for transmitting the received packets (300) from the second network element (102) through the packet network (103) back to the first network element (101) in response to the receiving of the packets at the second network element, characterised in that the second network element (102) further comprises: means (MCU, MEM, 707 - 709, CL) for transmitting a packet (300) arrived at the second network element (102) back to the first network element (101) only after a delay (Atbuf) from the receiving of the packet at the second network element. 14. A system according to claim 13, characterised in that the system is arranged to emulate the two-way information flow of an IP call for determining the Quality of Service (QoS). 15. A network element (102) for emulating the two-way information flow of a real application in a system, which in addition to said network element comprises a specific first network element (101) and a packet network (103) between the network element (102) and said first network element (101), which network element (102) comprises: means (MCU, MEM, 705, 706, CL) for receiving packets (300) transmitted from said first network element (101) through the packet network (103); means (MCU, MEM, 707 - 709, CL) for transmitting the received packets (300) through the packet network back to the first network element (101) in response to the receiving of the packets at the network element (102), characterised in that the network element (102) further comprises: means (MCU, MEM, 707 - 709, CL) for transmitting a packet (300) arrived at the network element (102) back to the first network element (101) only after a delay (AtbUf) from the receiving of the packet at the network element (102). 16. A network element according to claim 15, characterised in that the network element (102) is arranged to emulate the information flow of an IP call for determining the Quality of Service (QoS). 17. A computer program product executable in a network element (102) for emulating the information flow of a real application in a system, which in addition to said network element comprises a specific first network element (101) and a packet network (103) between the network element (102) and said first network element, which computer program product comprises a program code: for receiving at the network element (102) packets (300) transmitted from said first network element (101) through the packet network (103); for transmitting the received packets (300) through the packet network (103) back to the first network element (101) in response to the receiving of the packets at the network element (102), characterised in that the computer program product comprises a program code: for transmitting a packet (300) arrived at the network element (102) back to the first network element (101) only after a delay (AtbUf) from the receiving of the packet at the network element (102). 18. A computer program product according to claim 17, characterised in that the computer program product is arranged to emulate the information flow of an IP call for determining the Quality of Service (QoS). 19. A method for emulating the two-way information flow substantially as herein described with reference to the accompanying drawings. 20. A computer program product substantially as herein described with reference to the accompanying drawings. 21. A network element substantially as herein described with reference to the accompanying drawings.

Full Text

Emulating of Information Flow
The present invention relates to the emulating of the two-way information flow of a real application. Particularly, but not necessarily, the invention relates to the emulating of the information flow of a VoIP (Voice over Internet Protocol) call for determining the Quality of Service (QoS) at a VoIP application level.
Traditionally, when calling by telephone speech has been transferred in circuit-switched networks, such as in a Public Switched Telephone Network (PSTN). When calling by telephone in a digital circuit-switched network, a permanent connection of 64 kbps (kilo bits per second) is set up for each call. The standard band of the connection, 64 kbps, is due to the bit rate required in the sampling of analog speech when using 8-bit Pulse Code Modulation (PCM) at a sampling frequency of 8 kHz, which procedure enables the transmitting of analog speech having a frequency of 300 to 3400 Hz in a digital format.
The digital telephone network described above that is presently in common use is, however, very ineffective and thus consumes a lot of network resources. In the telephone network, the band for a connection is also reserved when the connection is not used actively, i.e. neither party of the connection is transferring information, such as speech or data, along the connection. The kind of use of a static band consumes a lot of data transmission resources, and as a result of this additional capacity must be invested in as the number of users increases. The type of ineffectiveness described above causes problems especially in calls between continents, where increasing the data transmission capacity is not as easy as in other cases. The problem is also partly manifest in call prices; expensive investments in capacity must be covered by high user charges.
To compensate and supplement calls that use a static band reservation in a telephone network, so-called VoIP calls, i.e. IP calls have been started to be marketed. Typically, the information transmitted in an IP call, such as speech, voice and/or video, is first converted from an analog format into a digital format, then compressed and converted into IP packets that are conveyed over an IP-based packet-switched network, such as the Internet network, sharing the band with other IP traffic. In IP calls, a band can be used in a considerably more effective way than in calls that reserve a static band, which is also shown in call prices. In addition, also new more effective coding schemes can be used, such as e.g. G.723.1 coding.

The time of arrival of transmitted IP packets to a receiver is not known before the packets arrive. And because IP routes the information flow packet by packet the time of propagation of packets from a sender to a receiver may vary greatly and the order of the packets may change. Furthermore, packets may be lost, for example, as a result of the overflows of incoming data that take place in the buffers of routers. By using a reliable protocol over IP, for example, packet losses can be identified automatically at a protocol level and the lost packets can be retransmitted. One such protocol is TCP (Transmission Control Protocol).
However, the retransmissions in question would cause additional varying delay in the transmission of information over the IP network. And since several applications used in repeating speech and/or picture transferred in real time do not function flawlessly if, for example, too much delay occurs in the transmission of information, TCP is not well suitable for use as a protocol to be used over IP in IP calls. Therefore, UDP (User Datagram Protocol), where there are no retransmissions, is normally used in IP calls. Instead, in a call setup, the use of TCP is recommendable so that the call setup would take place as reliably as possible.
For example, just for the reason that the applications used in repeating realtime information transmitted over an IP network have high realtime requirements in order to function flawlessly, at least some kind of arrangement is needed to guarantee the desired Quality of Service (QoS) for the IP call in question. IP as such does not provide QoS support in a form that it would provide a guaranteed Quality of Service. However, several different techniques exist with which a guaranteed QoS can be provided in an IP network. These are, among others, DiffServ (Differentiated Services) and IntServ (Integrated Services) techniques. Irrespective of which QoS technique is used, it is important that the QoS can be measured in order to find out whether it is really possible to provide a guaranteed QoS for each IP call.
Usually, several QoS parameters are required to describe a QoS. Thus, it is appropriate to measure values for a set of different QoS parameters, which in connection with VoIP are, for example, the following: end-to-end delay, end-to-end delay jitter, packet losses and packet loss correlation. Of these, end-to-end delay means the time that it takes for an IP packet to pass through an IP network from a sender to a receiver. End-to-end delay can also be measured as a round trip measurement, whereupon the time that it takes for an IP packet to pass from a sender to a receiver and back is measured. End-to-end jitter can be denoted, for

example, as a standard deviation or variance. Packet losses tell how many of the transmitted IP packets fail to be received on the receiving side, i.e. how many IP packets are lost on the way. As for the system performance, it is highly significant whether IP packets disappear or are lost one here and another there (no packet loss correlation) or whether several successive IP packets are lost (high packet loss correlation).
Figure 1 shows a principle of one QoS measurement according to prior art. There a stream of IP packets is transmitted from a first host 101 through an IP network 103 to a second host. Before transmitting, the first host 101 adds a first information to each IP packet to be transmitted. The stream of IP packets transmitted by the first host 101 is received at the second host 102, which adds a second information to the IP packets and returns them through the IP network 103 back to the first host 101, which adds a third information to the received IP packets.
Figure 2 illustrates the structure of an IP packet, the use of which is well known in the QoS measurement arrangement illustrated in Figure 1. An IP packet 200 comprises various types of fields for storing the information added by hosts to the IP packet. For example, in fields 201 and 202, the first host 101 stores just before transmitting the IP packet as said first information a time stamp data TST and a packet sequence number data SEQT respectively. In fields 203 and 204, the second host 102 stores as said second information on receiving the IP packet a time stamp data TS2and a packet sequence number data SEQ2 respectively. After receiving the IP packet, the second host 102 returns the IP packet immediately back to the first host 101 which stores, in a field 205, as said third information a time stamp data TS3 on receiving the IP packet. Now, of the QoS parameters, e.g. end-to-end delay drt can be determined by equation drt=TS3-TS1
In addition to the fields 201 - 205, the IP packet 200 in Figure 2 comprises a dummy length 206. The dummy length 206 is a data portion of a specific length with which the length of the IP packet can be adapted to the size of the packets of a realistic codec, such as G.711. If the IP packets 200 are yet transmitted as such a typically uniform stream of IP packets as is formed by a realistic codec, a real IP call and its QoS measurements can be emulated by the arrangement presented above.

However, the arrangemen; according to prior art described above has its problems. Let us assume ;hat a stream of IP packets 200 is sent from the first host 101 through the IP network 103 to the second host 102 and that the transmitting of the IP packets from the first host to the second takes place uniformly. In an ideal case, the time of transmission of all the IP packets (end-to-end delay) from the first host to the second is the same, whereupon the IP packets sent from the first host would also arrive at the second host uniformly. However, in reality, the situation is typically such that, for example, due to a varying IP network load IP packets do not arrive at the second host uniformly but burstly. By this is meant that the stream of IP packets arriving at the second host comprises densities (clusters of IP packets) and spacings (there is an exceptionally long pause between IP packets) instead of a steady stream.
When the second host now returns each IP packet it has received back to the first host, the stream of returned IP packets is already on leaving the second host bursty and not uniform as it would be in the case of a realistic IP call. In this case, the QoS experienced by the bursty stream of IP packets returning from the second host to the first host is normally worse than the QoS experienced by the stream of IP packets transmitted uniformly from the first host to the second host. This asymmetry is not characteristic of a real IP call and it distorts the measuring of the values of QoS parameters. Furthermore, if IP packets sent by the first host are lost on their way to the second host, the stream of IP packets returned from the second host to the first has less IP packets than in the original stream of IP packets sent from the first host to the second. In this case, more additional spacings are automatically formed in the stream of IP packets returned from the second host to the first, which again increases asymmetry.
Thus, the measurement arrangement according to prior art presented above is not
suitable in the best possible way for the QoS measurements of an IP call. Now, a
new solution has been invented, which is suitable for making QoS measurements
of an IP call. According to a first aspect of the invention, there is implemented a
method for emulating the two-way information flow of a real application in a
system, which comprises a first network element and a second network element,
as well as a packet network between said first network element and said second
network element, which method comprises:
transmitting a set of packets from the first network element through the packet
network to the second network element;
receiving at least part of the transmitted packets at the second network element;

transmitting the received packets from the second network element through the
packet network back to the first network element in response to the receiving of
the packets at the second network element.
It is characteristic of the method that it comprises:
transmitting a packet arrived at the second network element back to the first
network element only after a delay from the receiving of the packet at the second
network element.
According to a second aspect of the invention, there is implemented a system for
emulating the two-way information flow of a real application, which system
comprises a first network element and a second network element, as well as a
packet network between said first network element and said second network
element, which first network element comprises:
means for transmitting a set of packets from the first network element through the
packet network to the second network element, and the second network element
comprises:
means for receiving at least part of the transmitted packets at the second network
element;
means for transmitting the received packets from the second network element
through the packet network back to the first network element in response to the
receiving of the packets at the second network element.
It is characteristic of the system that the second network element further
comprises:
means for transmitting a packet arrived at the second network element back to the
first network element only after a delay from the receiving of the packet at the
second network element.
According to a third aspect of the invention, there is implemented a network
element for emulating the two-way information flow of a real application in a
system, which in addition to said network element comprises a specific first
network element and a packet network between the network element and said first
network element, which network element comprises:
means receiving packets transmitted from said first network element through the
packet network;
means for transmitting the received packets through the packet network back to
the first network element in response to the receiving of the packets at the network
element.
It is characteristic of the network element that the network element further
comprises:

means for transmitting a packet arrived at the network element back to the first network element only after a delay from the receiving of the packet at the network
element.
According to a fourth aspect of the invention, there is implemented a computer
program product executable in a network element for emulating the information
flow of a real application in a system, which in addition to said network element
comprises a specific first network element and a packet network between the
network element and said first network element, which computer program product
comprises a program code:
for receiving at the network element packets transmitted from the first network
element through the packet network;
for transmitting the received packets through the packet network back to the first
network element in response to the receiving of the packets at the network
element.
It is characteristic of the computer program product that the computer program
product comprises a program code:
for transmitting a packet arrived at the network element back to the first network
element only after a delay from the receiving of the packet at the network element.
In a preferred embodiment of the invention, said network elements are computers, such as PCs (Personal Computer), workstation computers or network server computers, and said packets are communication packets, such as IP packets. The present invention enables better emulating of the two-way information flow of a real application, such as the information flow of an IP call, at an application level with uniform streams of IP packets and signalling than is known from prior art and thus, the performing of more reliable QoS measurements than the known solutions. The invention can be used, among other things, in network designing and for testing the performance of a network from the viewpoint of VoIP.
By the term IP network is meant in this description besides networks based on IP, such as Internet and Intranet networks, also other similar packet networks, such as the X.25 network. By the IP call is meant a call where information, preferably speech, voice, video or multimedia, is transferred over this kind of network typically for implementing a realtime service. Thus, the invention can also be used for emulating a vi8eoconference.
In the following, the invention will be described in detail by referring to the enclosed drawings, in which

Figure 1 shows the principle of one QoS measurement according to prior art;
Figure 2 shows the structure of an IP packet used in one QoS measurement according to prior art;
Figure 3 illustrates the structure of an IP packet suitable for the implementation of one embodiment of the invention;
Figure 4 shows an exemplary case with the help of which one embodiment of the invention is illustrated;
Figure 5 is a diagram of a time domain illustrating the exemplary case shown in Figure 4; and
Figure 6 illustrates hardware for implementing the invention.
Figures 1 and 2 were already explained above in connection with the description of prior art. Next, a preferred embodiment of the invention will be explained where an IP call between a first host and a second host is emulated and QoS measurements are performed. Roughly, Figure 1 can also illustrate a measurement arrangement according to the invention. In a preferred embodiment of the invention, a first host 101 transmits through an IP network 103 to a second host 102 a similar uniform stream of IP packets as is formed by a realistic codec, such as G.711, where the size of the IP packets corresponds to the size of the packets formed by the real codec. The IP packets are preferably transmitted by using UDP over IP. Figure 3 illustrates the structure of an IP packet, which is used in the preferred embodiment of the invention. An IP packet 300 comprises various types of fields for storing the information added by the hosts to each IP packet at specific moments of time. In fields 301 and 302 of each IP packet, the first host 101 stores as first information just before transmitting each IP packet 300 a time stamp data TS-i and a packet sequence number data SEQ1 respectively. For example, when transmitting a first IP packet the first host stores as the time stamp data TSi of the IP packet in question the time of transmission of the IP packet in question and as the sequence number data SEQltthe number 1. Correspondingly, as the time stamp data TSi of a second IP packet the transmitting time of the second IP packet is stored and as the sequence number SEQ1tthe number 2 and so on.

As the IP packets of the stream of IP packets arrive at the second host 102, the second host stores in fields 303 and 304 of each IP packet as second information a time stamp data TS2 ano a packet sequence number data SEQ2 respectively. When the first IP packet (which is not necessarily the IP packet the first host
> transmitted first) of the stream of IP packets arrives at the second host, the second host then stores the time of arrival of the IP packet in question at the second host as the time stamp data TS2 of the IP packet in question and the number 1 as the sequence number data SEQ2i. Correspondingly, the time of arrival of the second IP packet at the second host is stored as the time stamp data
i TS2 of the IP packet in question and the number 2 as the sequence number SEQ2, and so on.
However, according to the invention, the IP packets arrived at the second host are not returned immediately to the first host, but they (or their data) are guided into a buffer at the second host from where they are then transmitted in the order of arrival back to the first host as a similar uniform stream of IP packets as is formed by a realistic codec used in an IP call. In this way, asymmetry can be eliminated in the transmitting of IP packets better than in solutions known from prior art. When transmitting each buffered IP packet back to the first host, the second host stores in a field-305 of each IP packet as third information a time stamp data TS3. The transmitting time of each IP packet is stored as the time stamp data TS3.
As the IP packets of the stream of IP packets returned from the second host to the first host arrive at the first host, the first host stores in a field 306 of each IP packet as fourth information a time stamp data TS4. The time of arrival of each IP packet at the first host is stored as the time stamp data TS4. Preferably, for indicating the sequence in which the IP packets return to the first host a new sequence number indicator (e.g. SEQ3) is not required if the received IP packets (or the data comprised by them) are stored in the same sequence as they arrived at the first host. Naturally, using the sequence number indicator SEQ3 in connection with the invention is possible however.
In addition to the fields 301 - 306, the IP packet 300 in Figure 3 comprises a dummy length 307. The dummy length 307 is a data portion of a specific length , which does not necessarily have any significance other than that with it the length of an IP packet can be adapted to the size of the packets of a realistic codec, such as G.711. In addition to the fields shown in Figure 3, the IP packet 300 typically comprises IP and UDP headers, among other things, for the address

information and port numbers of a sender and a receiver. The content of the fields 301 - 307 can be called by the term payload.
Now, of the QoS parameters, a round trip end-to-end delay drt can be determined by the equation dn.new = TS4 - TS1 - (TS3 - TS2). If the clocks of the first and second hosts have been synchronised, one-way end-to-end delays can be calculated by using the equations d0W|1 = TSi'- TSj (the trip from the second host to the first) and d0Wt2 = TS4 - TS3 (the return trip from the second host to the first). In synchronising the hosts, e.g. GPS (Global Positioning System) can be used.
Material for calculating the end-to-end delay jitter is obtained, for example, by calculating the differences between the time stamps TS2 of successive IP packets arrived at the second host. On the basis of the differences, for example, the standard deviation and/or variance of the end-to-end delay jitter (from the first host to the second host) can then be calculated.
Packet losses can be found out when the number of transmitted IP packets is known. In this case, when the stream of IP packets has gone the round trip between the first and second hosts, for example, the number of packets lost during the first part can be found out by subtracting the number of IP packets arrived at the second host from the number of packets transmitted.
Packet loss correlation (here from the first host to the second host) can be examined by studying the sequence numbers SEQT of the IP packets received at the second host and by seeing which sequence numbers are missing.
Next, the implementation of the preferred embodiment of the invention will be presented in more detail with the help of an exemplary case by referring to Figures 4 and 5 of which Figure 4 shows the basic arrangement in the exemplary case and Figure 5 is the diagram of a time domain for illustrating the exemplary case. In Figure 5, the left time axis shows the time according to the clock of the first host and the right time axis shows the time according to the clock of the second host. The clocks of the first and second hosts can be synchronised with each other.
Let us assume that the number of IP packets to be transmitted N = 4. In transmitting the IP packets, the transmitting interval of IP packets formed by a realistic codec, be it Atti, is emulated. Prior to the QoS measurements, a message is sent from the first host to the second host, wherein the values of the parameters N, Atti and the buffer delay Atbuf are indicated to the second host. It must be noted

here that although for reasons of simplicity in this exemplary case the number of : IP packets transmitted N = 4, in reality the number of IP packets transmitted can be considerably higher, e.g. several hundreds or thousands.
Now, from the first host 101 to the second host 102 through the IP network 103 a stream of IP packets is transmitted where, in a first IP packet (packet A), the sequence number SEQt = 1 and the time stamp TST are stored just before the transmitting of the IP packet in question at the moment of time tlf in a second IP packet (packet B), the sequence number SEQ1 = 2 and the time stamp TSi are stored at the moment of time t2, in a third IP packet (packet C), the sequence number SEQT = 3 and the time stamp TSi are stored at the moment of time t3, and in a fourth IP packet (packet D), the sequence number SEQT = 4 and the time stamp TST are stored at the moment of time t4. The IP packets are transmitted at intervals of Atti, whereupon t2 - U =Atlit t3 -t2 =Atti and t4 -13 =Atti. Said moments of time t1( t2, t3 and U are according to the clock of the first host.
After getting the message from the first host, in which message the number of the IP packets transmitted N is indicated to be four, the second host stores in a specific (transmitting) buffer four IP packets the sequence numbers of which are SEQ2 = -1 (the first IP packet to be transmitted from the buffer (packet E)), SEQ2 = -2 (the second packet (packet F)), SEQ2 = -3 (the third packet (packet G)), SEQ2 = -4 (the fourth packet (packet H)).
After receiving, at the moment of time t5, the first of the IP packets transmitted by the first host, which here is the IP packet (packet A) that was also transmitted first (this is not always the case, e.g. if the first IP packet is lost on the way), the second host stores in the IP packet in question (packet A) the time stamp TS2 and stores as the sequence number SEQ2 = 1. After this, the second host copies the time stamp and sequence number data (TSi, SEQT = 1, TS2 and SEQ2 = 1) of the IP packet in question (packet A) in the IP packet (packet E) that is in the buffer the first in turn to be transmitted whereupon, among other things, in the IP packet that is in the buffer the first in turn to be transmitted, the sequence number (packet E) SEQ2 = -1 is substituted by the number 1. The packet E is now transmitted from the second host to the first host after the buffer delay AtbUf, at the moment of time tn = t5 + Atbuf. Just before transmitting, the second host stores, in the packet E, the time stamp TS3. This takes place approximately at the moment of time t^.
When the stream of IP packets to be returned has now begun, the other three IP packets (packets F, G and H) waiting to be transmitted in the buffer of the second

host at intervals of Atti at the moments of time t12 (packet F), t13 (packet G), and t14 (packet H), whereupon if for the packets E, F, G and H index numbers j = 1, 2, 3, 4 respectively are used, the transmitting time t^ of each packet according to the clock of the second host is obtained from the equation t1( = t5 + Atbuf + (j - 1) Atti.
Correspondingly, when receiving some other (than the packet A described above) IP packet belonging to a stream of IP packets sent from the first host to the second host, the second host stores in the received packet the time stamp TS2 and the sequence number SEQ2i after which the second host copies the data of the received IP packet in such an IP packet in the transmitting buffer of the second host that is next in turn to be transmitted, wherein the data of some arrived IP packet has not yet been copied. Before transmitting each IP packet, the second host yet stores in each packet to be transmitted the time stamp TS3. Thus, in the situation illustrated by Figures 4 and 5, after receiving the packet B the second host stores therein the time stamp TS2 at the moment of time t6 and the sequence number SEQ2 = 2, because the packet B is the second IP packet that arrives at the second host. The data of the packet B are copied in the packet F waiting to be transmitted in the buffer whereupon, among other things, the sequence number of the packet F SEQ2= -2 is substituted by the number 2. The packet F is transmitted at the moment of time t12. Just before transmitting the time stamp TS3 is stored in the packet F,
Next, a situation where a packet loss takes place will be examined in the exemplary case shown in Figures 4 and 5. Let us assume that the packet C disappears and fails to arrive at the second host. Because the buffer delay Atbuf in this case is so long that the packet (packet D) transmitted next nevertheless manages to arrive at the second host at the moment of time t8, which is before the transmitting time of the packet G t13 = t5 + Atbuf + 2 Atti (the packet G is the packet wherein the data of the packet C should be copied for return transmission), instead of the lost packet C the data of the packet D (TS1f SEQ1 = 4, TS2 and SEQ2 = 3) are copied in the packet G whereupon, among other things, the sequence number of the packet G SEQ2 = -3 is substituted by the number 3. The packet G is transmitted at the moment of time t13. The time stamp TS3 is stored in the packet G just before transmitting.
Because the packet C failed to arrive at the second host, there is no such IP packet arrived at the second host from which data would not already have been copied in some packet, whereupon there is nothing to copy in the packet H. In order that a uniform stream of IP packets could be maintained, the packet H is

nevertheless transmitted as a so-called dummy packet (filling packet) at the moment of time of transmission t14, although it does not now comprise values based on real time stamp and sequence number data for TS1( SEQ-t and TS2. Before transmitting the time stamp TS3 is stored in the packet H. Since a new sequence number SEQ2 was not copied in the packet H either, the original negative sequence number SEQ2 = -4 remains as the sequence number of the packet H.
When the packets E, F, G and H arrive at the first host at the moments of time t15l t16, t17 and t18 respectively, the first host stores therein the time stamps TS4. For the QoS parameters, values can now be determined as was already described above. If the sequence number of some received IP packet SEQ2 is negative, the first host will identify it as a dummy packet, whereupon it does not take into account the information possibly found in the fields 301 (TSj), 302 (SEQ}) and/or 303 (TS2) of the dummy packet, because this information is not based on real time stamp or sequence number data. The existence of dummy packets in the returned steam of IP packets normally means that at least one of the IP packets originally transmitted from the first host to the second has failed to arrive at the second host or has arrived there too late. In the invention, however, error situations like this have been taken into consideration in the manner presented above (e.g. by the use of dummy packets), and the emulating of a realistic IP call and the QoS measurements will succeed even if packet losses occured.
In an IP call, where realtime speech is transferred, there normally occur talkspurts and silent periods (pauses). This is due to the fact that when one party of the IP call speaks, the counter party normally is silent. For some VoIP terminals (wireless terminal, telephones), VAD (Voice Activity Detection) detectors have been developed, which operate so that when the level of a speech signal coming into the VAD detector falls below a specific limit (speaker is silent), IP packets will no longer be transmitted to the receiving end. In this case, data transmission band is saved.
Next, the description of the invention will be supplemented by presenting how for performing QoS measurements an IP call is emulated according to the invention, the parties of which have a VAD function in their VoIP terminals. IP packets are now transmitted from the first host to the second host still at intervals of Atti, but when an amount of Nts IP packets have been transmitted, a pause is made in the transmitting of IP packets that will last for a period of NspAtti. After this, a new value is allotted for N^ and IP packets are transmitted for a period of NtsAttj. Then, a new

value is allotted for Nsp and a pause is again made in the transmitting of IP packets for a period of NspAtti and so on. The figures Nts and Nsp are allotted from random distribution functions P(Nts) and P(Nsp) respectively, of which P(Nts) emulates the distribution of the lengths of talkspurts and P(Nsp) the distribution of the lengths of silent periods in a real IP call. The material for forming the distributions P(Nts) and P(Nsp) has been obtained, for example, by measuring lengths of talkspurts and pauses in real IP calls.
In practice, the values of Nts and Nspcan be allotted for each talkspurt and silent period independently irrespective of each other in the first and second hosts. And since the information about the number N of the packets transmitted has already before the commencement of QoS measurements been delivered from the first host to the second, the total number of IP packets transmitted in both directions will tally. Alternatively, the values of Nts and Nspcan only be allotted in the first host, in which case the transmission of IP packets returned by the second host to the first host can be timed for a time period when IP packets are not arriving at the second host. So here the second host "is listening" whether IP packets are coming in and, if they are not, the second host starts the returning of the IP packets that are in the buffer, to the first host. In practice, "listening" can be implemented, for example, so that if IP packets have not arrived at the second host within a specific time (e.g. buffer delay Atbuf), the second host concludes that the first host has a silent period going, whereupon it starts the returning of IP packets to the first host.
This description has above concentrated on describing the emulating of an IP call and the performing of the QoS measurements of the IP call. Because, in a real IP call, UDP is used where no retransmissions and acknowledgements are used, naturally these do not occur in the description of the invention either. However, in an IP call setup, a reliable protocol must be used, whereupon the retransmissions and acknowledgements of packets become of interest. Well-known VoIP signalling protocols are, among others, H.323 and SIP (Session Initiation Protocol). Signalling protocols enable in a call setup, for example, the fact that a VoIP terminal (first host) that is making an IP call and a VoIP terminal (second host) that answers the IP call can communicate to each other what type of codec each of the call party has in its use. For example, in H.323, most of the signalling used in a call setup takes place by using a reliable protocol, TCP. According to the invention, the setting up of an IP call is emulated by sending one or more IP packets from the first host to the second, depending on the signalling protocol to be emulated. Said IP packet used for emulating the call setup is otherwise similar to the IP packet 300 described above, but instead of the UDP-header it comprises

a TCP header. Thus, in emulating a call setup, IP packets are preferably transmitted by using TCP over IP. A TCP header typically comprises, among other things, information that can be used in retransmitting lost IP packets.
In emulating a call setup, always after receiving an IP packet transmitted by the first host the second host immediately transmits the same IP packet back to the first host. Now, the call setup time can be measured, which is the time that is consumed from the transmitting of the first IP packet to the receiving of the last IP packet at the first host. Alternatively, it is possible to transmit from the first host only one IP packet and wait for it to return from the second host. When the returned IP packet is received at the first host, the call setup time can now be approximated by multiplying the time between the transmitting of the IP packet and the receiving of the returned IP packet, e.g. by some number suitable for the purpose. In determining the call setup time, the time stamps TS2 and TS3 are not necessarily needed at all, because the IP packet is transmitted back immediately after arriving at the second host. The time between the transmitting of the IP packet and the receiving of the returned IP packet is obtained by subtracting the time stamp TST from the time stamp TS4.
Naturally, the actual emulating of an IP call and the QoS measurements of the IP call will be commenced only after the emulating of signalling related to the call setup has been completed.
Figure 6 shows hardware suitable for implementing the invention. The hardware comprises a first host 101 and a second host 102, as well as an IP network 103 between the hosts. The hosts can be, e.g. PCs that can be coupled to the IP network 103, for example, with a network access card (not shown in the figure). The first and second hosts comprise a unit MCU (Master Controlling Unit) that controls the host, as well as a memory MEM. The MCU can be, e.g. a microprocessor. Blocks 701-709 are functional blocks, wherein the MCU is arranged to carry out specific activities on the basis of a program stored in the MEM of the host. In the block 701, a time stamp data TS! is stored in the IP packets to be transmitted according to a clock CL of the first host just before transmitting, and a sequence number data SEQt. In the block 702, the IP packets are transmitted to the second host 102 through the IP network 103. In the block 705, the second host 102 receives the IP packets transmitted by the first host 101, wherein, in the block 706, a time stamp data TS2 is stored according to the clock CL of the system and a sequence number data SEQ2. In the block 707, the time stamp and sequence number data of the received IP packets TS-,, SEQ-,, TS2 and

SEQ2 are copied in the IP packets waiting to be transmitted in a buffer. In the block 708, a time stamp data TS3 is stored in the IP packets to be transmitted to the first host according to the clock CL of the second host just before transmitting. In the block 709, the IP packets are transmitted to the first host 101 through the IP network 103. In the block 703, the first host receives the IP packets transmitted by the second host 102 wherein, in the block 704, a time stamp data TS4 is stored according to the clock CL of the first host.
In practice, in the memory MEM of the hosts, there is a storage area wherein the MCU typically stores the content of each IP packet to be transmitted (time stamp and sequence number data). Thus, in transmitting an IP packet it is just this content of the storage area that is sent to the receiving end. By said storage area is meant, for example, the buffer in the second host mentioned above, wherein the IP packets are waiting to be transmitted to the first host. At the receiving end, the MCU stores the data of the received IP packets in its memory MEM, in a file, for a later analysis, such as for calculating the QoS parameters.
Thus, the essential parts of the invention can be implemented programmably. The computer program products in question stored in the memories MEM of the hosts can be programmed in a programming language suitable for the purpose, such as C programming language.
Because the invention provides means for emulating more accurately a realistic IP call at an application level with signalling and symmetric uniform IP packet streams than is known from solutions according to prior art, the invention enables the carrying out of the QoS measurements of an IP call more reliably than the known solutions. In the arrangement according to the invention, error situations of an IP network are also prepared for, whereupon with the arrangement according to the invention reliable QoS measurements can also be carried out when IP packets of an IP call are lost along the way or when they arrive at the receiving end too late.
Although above, in the description of the invention, an arrangement was described which comprises two hosts and a packet network between them, there can also be more hosts. Thus, from a first host a stream of IP packets can be transmitted to two or more second hosts, which will all return the IP packets transmitted by the • first host. For example, in this way, it is possible to emulate an IP group call, which is made from one VoIP terminal to two or more VoIP terminals and carry out the QoS measurements. Furthermore, according to the invention, it is possible to

emulate more than one IP call simultaneously or nonsimultaneously and thus, carry out the QoS measurements using several different pairs of hosts.
This description presents the implementation and embodiments of the present invention, with the help of examples. For a person skilled in the it is apparent that the present invention is not restricted to details of the embodiments presented above, and that the invention can also be implemented in another form without deviating from the characteristics of the invention. The embodiments presented above should be considered illustrative, but not restricting. Thus, the possibilities of implementing and using the invention are only restricted by the enclosed claims. Consequently, the various options of implementing the invention as determined by the claims, including the equivalent implementations, also belong to the scope of the invention.

Claims
1. A method for emulating the two-way information flow of a real application in a
system, which comprises a first network element (101) and a second network
element (102), as well as a packet network (103) between said first network
element and said second network element, which method comprises:
transmitting a set of packets (300) from the first network element through the packet network to the second network element;
receiving at least part of the transmitted packets at the second network element;
transmitting the received packets from the second network element through the packet network back to the first network element in response to the receiving of the packets at the second network element, characterised in that the method comprises
transmitting a packet arrived at the second network element back to the first network element only after a delay from the receiving of the packet at the second network element.
2. A method according to claim 1, characterised in that the method comprises:
transmitting said set of packets from the first network element through the packet network to the second network element as a uniform stream of packets; and
in response to the receiving of the packets at the second network element, transmitting the received packets to the first network element as a uniform stream of packets emulating a real IP (Internet Protocol) call at an application level for determining the Quality of Service (QoS).
3. A method according to claim 1, characterised in that, in the method, the packets transmitted are IP packets that correspond in size to IP packets transmitted in a real IP call.
4. A method according to claim 1, characterised in that, in transmitting a packet (300), UDP (User Datagram Protocol) over IP is used.

5. A method according to claim 1, characterised in that said network elements (101, 102) are computers.
6. A method according to claim 1, characterised in that the method comprises for emulating a group call, transmitting from the first network element through

the packet network a set of packets to a set of second network elements, which, in response to the receiving of the packets, return the packets they have received back to the first network element.
7. A method according to claim 1, characterised in that the method comprises using more than one network element pair, formed by the first and second network elements, for emulating more than one IP call.
8. A method according to,claim 1, characterised in that the method comprises emulating the call setup of an IP call by transmitting before transmitting said set of packets at least one packet from the first network element through the packet network to the second network element and by returning said at least one packet back to the first network element immediately after it has arrived at said second network element.
9. A method according to claim 8, characterised in that, in transmitting said at least one packet, TCP (Transmission Control Protocol) over IP is used.
10. A method according to claim 1, characterised in that when the second network element is about to return the packets it has received from the first network element in a case, where the second network element lacks the packet to be returned, a filling packet is transmitted from the second network element to the first network element for maintaining a uniform stream of packets.
11 .A method according to claim 1, characterised in that the method comprises transmitting first said set of packets from the first network element through the packet network to the second network element, after which a pause of a specific length (NspAtti) is made in the transmitting of the packets, after which pause a second set of packets is transmitted from the first network element through the packet network to the second network element for emulating the talkspurts and silence periods of an IP call.
12. A method according to claim 1, characterised in that the method comprises: storing in a packet to be transmitted from the first network element, in connection with the transmitting of the packet, a first time information (TSi) and a first sequence number data (SEQ0;

storing in a packet received at the second network element, in connection with the receiving of the packet, a second time information (TS2) and a second sequence number data (SEQ2);
storing at the second network element in a packet to be returned to the first network element, in connection with the return transmission of the packet, a third time information (TS3);
storing at the first network element in a packet returned to the first network element, in connection with the receiving of the packet, a fourth time information (TS4);
determining on the basis of said time information (TST - TS4) and sequence number data (SEQ-j - SEQ4) values for a set of parameters describing the Quality of Service for determining the Quality of Service (QoS).
13. A system for emulating the two-way information flow of a real application, which system comprises a first network element (101) and a second network element (102), as well as a packet network (103) between said first network element and said second network element, which first network element (101) comprises:
means (MCU, MEM, 701, 702, CL) for transmitting a set of packets (300) from the first network element (101) through the p'acket network (103) to the second network element (102), and the second network element comprises:
means (MCU, MEM, 705, 706, CL) for receiving at least part of the transmitted packets (300) at the second network element (102);
means (MCU, MEM, 707 - 709, CL) for transmitting the received packets (300) from the second network element (102) through the packet network (103) back to the first network element (101) in response to the receiving of the packets at the second network element, characterised in that the second network element (102) further comprises:
means (MCU, MEM, 707 - 709, CL) for transmitting a packet (300) arrived at the second network element (102) back to the first network element (101) only after a delay (Atbuf) from the receiving of the packet at the second network element.
14. A system according to claim 13, characterised in that the system is arranged to emulate the two-way information flow of an IP call for determining the Quality of Service (QoS).
15. A network element (102) for emulating the two-way information flow of a real application in a system, which in addition to said network element comprises a

specific first network element (101) and a packet network (103) between the network element (102) and said first network element (101), which network element (102) comprises:
means (MCU, MEM, 705, 706, CL) for receiving packets (300) transmitted from said first network element (101) through the packet network (103);
means (MCU, MEM, 707 - 709, CL) for transmitting the received packets (300) through the packet network back to the first network element (101) in response to the receiving of the packets at the network element (102), characterised in that the network element (102) further comprises:
means (MCU, MEM, 707 - 709, CL) for transmitting a packet (300) arrived at the network element (102) back to the first network element (101) only after a delay (AtbUf) from the receiving of the packet at the network element (102).
16. A network element according to claim 15, characterised in that the network element (102) is arranged to emulate the information flow of an IP call for determining the Quality of Service (QoS).
17. A computer program product executable in a network element (102) for emulating the information flow of a real application in a system, which in addition to said network element comprises a specific first network element (101) and a packet network (103) between the network element (102) and said first network element, which computer program product comprises a program code:
for receiving at the network element (102) packets (300) transmitted from said first network element (101) through the packet network (103);
for transmitting the received packets (300) through the packet network (103) back to the first network element (101) in response to the receiving of the packets at the network element (102), characterised in that the computer program product comprises a program code:
for transmitting a packet (300) arrived at the network element (102) back to the first network element (101) only after a delay (AtbUf) from the receiving of the packet at the network element (102).
18. A computer program product according to claim 17, characterised in that the
computer program product is arranged to emulate the information flow of an IP
call for determining the Quality of Service (QoS).

19. A method for emulating the two-way information flow substantially as herein described with reference to the accompanying drawings.
20. A computer program product substantially as herein described with reference to the accompanying drawings.
21. A network element substantially as herein described with reference to the
accompanying drawings.

Documents:

in-pct-2002-1231-che-abstract.pdf

in-pct-2002-1231-che-claims filed.pdf

in-pct-2002-1231-che-claims granted.pdf

in-pct-2002-1231-che-correspondnece-others.pdf

in-pct-2002-1231-che-correspondnece-po.pdf

in-pct-2002-1231-che-description(complete)filed.pdf

in-pct-2002-1231-che-description(complete)granted.pdf

in-pct-2002-1231-che-drawings.pdf

in-pct-2002-1231-che-form 1.pdf

in-pct-2002-1231-che-form 26.pdf

in-pct-2002-1231-che-form 3.pdf

in-pct-2002-1231-che-form 5.pdf

in-pct-2002-1231-che-other document.pdf

in-pct-2002-1231-che-pct.pdf

« Previous Patent

Next Patent »

Patent Number

210783

Indian Patent Application Number

IN/PCT/2002/1231/CHE

PG Journal Number

50/2007

Publication Date

14-Dec-2007

Grant Date

08-Oct-2007

Date of Filing

09-Aug-2002

Name of Patentee

M/S. NOKIA CORPORATION

Applicant Address

Keilalahdentie 4, FIN-02150 Espoo,

Inventors:

#	Inventor's Name	Inventor's Address
1	VILHO RAISANEN	Laajavuorenrinne 6 E 29, FIN-01620 Vantaa,
2	PEKKA PESSI	Keiteleentie 1C 18, FIN-00550 Helsinki,

PCT International Classification Number

H04L 1/18,12/26

PCT International Application Number

PCT/FI2001/000033

PCT International Filing date

2001-01-15

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	20000316	2000-02-14	Finland