learning centre
This section demonstrates some of the capabilities of the TraceAnalyser software.
Video streaming setup
The setup delay of a video streaming session is defined as the delay between the TCP socket establishment (or the DNS lookup of the video server if present) until the start of the transmission of the RTP packets. Basically, this delay comprises by the TCP socket establishment delay and the RTSP session setup delay.
The graph shows the average video streaming setup delay (in seconds) of the entire sample and also the average delay of the three mostly observed phones. Evidently, Nokia N70 is the quickest with an average delay of about 2.5 sec.
Video streaming buffering
Buffering is used in order to smooth out the jitter between arriving packets due to the network transmission. In this example, a buffering delay of 8 sec was employed and the graph shows that the reception of the streaming packets was smooth throughout the streaming session since the buffer size remained close to 8 sec.
This is a video streaming session which resulted in rebuffering. At a particular instant a buffer at the network side started growing (denoted by the increasing round-trip-time RTT line) and when it became full (the RTT line leveled off) substantial packet loss occurred. This resulted in a smaller number of packets arriving at the client side which was depicted by the decreasing buffer line. Of course, when the buffer line reached zero, the normal playback terminated and rebuffering event occurred.
WAP delay profile
The delay profile to access a specific static page of about 12 kBytes at the WAP server is depicted. The used mobile devices were using the HTTP/TCP set of protocols to access WAP content, and also before the access they were not PS attached.
The average page download delay was measured at 10.5 sec, and as the graph shows almost 60% of this delay was due to the signalling needed for PS attach and PDP context activation procedures. Interestingly, the WAP server was found to contribute 28.6% of the total delay which is about 3 sec, hence the proper functioning of the server has to be further investigated. The actual transport of the content required only 2.9% the total delay.