The most well known use of this scheme is telephony speech (e.g. GSM), but with Internet and multimedia a number of new applications will require this scheme, for example voice over IP and video conferencing tools. Real time conversation is always performed between peers (or groups) of live (human) end-users. This is the only scheme where the required characteristics are strictly given by human perception (the senses). Therefore this scheme raises the strongest and most stringent QoS requirements. The real time conversation scheme is characterised by that the transfer time shall be low because of the conversational nature of the scheme and at the same time that the time relation (variation) between information entities of the stream shall be preserved in the same way as for real time streams. The maximum transfer delay is given by the human perception of video and audio conversation. Therefore the limit for acceptable transfer delay is very strict, as failure to provide low enough transfer delay will result in unacceptable lack of quality. The transfer delay requirement is therefore both significantly lower and more stringent than the round trip delay of the interactive traffic case. Real time conversation - fundamental characteristics for QoS:

• preserve time relation (variation) between information entities of the stream
• conversational pattern (stringent and low delay)

The resulting overall requirement for this communication scheme is to support conversational real time services with low transfer delay as given by the human perception. (There are less hard requirements on packet loss ratio.) A real-time streaming application is one that delivers time-based information in real-time, where time-based information is user data that has an intrinsic time component. Video, audio and animation are examples of time-based information, in that they consist of a continuous sequence of data blocks that shall be presented to the user in the right sequence at pre-determined instants. Conversational voice Audio transfer delay requirements depends on the level of interactivity of the end users. To preclude difficulties related to the dynamics of voice communications, ITU-T Recommendation G.114 [19] recommends the following general limits for one-way transmission time (assuming echo control already taken care of): The human ear is highly intolerant of short-term delay variation (jitter) it is therefore paramount that this is reduced as lower level as is practical. A limit as low as 1 msec is suggested as a target. Requirements for information loss are influenced by the fact that the human ear is tolerant to a certain amount of distortion of a speech signal. It is has been suggested in studies that acceptable performance is typically obtained with frame erasure rates (FER) up to 3 %. A connection for a conversation normally requires the allocation of symmetrical communication resources, with the average hold time of a call being in the region of 2 minutes. Videophone Videophone implies a full-duplex system, carrying both video and audio and intended for use in a conversational environment. As such, in principle the same delay requirements as for conversational voice will apply, i.e. no echo and minimal effect on conversational dynamics, with the added requirement that the audio and video must be synchronised within certain limits to provide "lip-synch" (i.e. synchronisation of the speaker's lips with the words being heard by the end user). In fact, due to the long delays incurred in even the latest video codecs, it will be difficult to meet these requirements. Once again, the human eye is tolerant to some loss of information, so that some degree of packet loss is acceptable depending on the specific video coder and amount of error protection used. It is expected that the latest video codecs will provide acceptable video quality with frame erasure rates up to about 1%. Interactive games Requirements for interactive games are obviously very dependent on the specific game, but it is clear that demanding applications will require very short delays, and a value of 250 msec is proposed, consistent with demanding interactive applications. Two-way control telemetry Two-way control telemetry is included here as an example of a data service which does require a real-time streaming performance. Clearly, two-way control implies very tight limits on allowable delay and a value of 250 msec is proposed, but a key differentiator from the voice and video services in this category is the zero tolerance for information loss (obvious if you are controlling an important industrial process, for example). Telnet Telnet is included here with a requirement for a short delay in order to provide essentially instantaneous character echo-back.

When the end-user, that is either a machine or a human, is on line requesting data from remote equipment (e.g. a server), this scheme applies. Examples of human interaction with the remote equipment are: web browsing, data base retrieval, server access. Examples of machines interaction with remote equipment are: polling for measurement records and automatic data base enquiries (tele-machines). Interactive traffic is the other classical data communication scheme that on an overall level is characterised by the request response pattern of the end-user. At the message destination there is an entity expecting the message (response) within a certain time. Round trip delay time is therefore one of the key attributes. Another characteristic is that the content of the packets must be transparently transferred (with low bit error rate). Interactive traffic - fundamental characteristics for QoS:

• request response pattern
• preserve payload content

The resulting overall requirement for this communication scheme is to support interactive non-real time services with low round-trip delay. Voice messaging and dictation Requirements for information loss are essentially the same as for conversational voice, but a key difference here is that there is more tolerance for delay since there is no direct conversation involved. The main issue, therefore becomes one of how much delay can be tolerated between the user issuing a command to replay a voice message and the actual start of the audio. There is no precise data on this, but a delay of the order of a few seconds appears reasonable for this application. Data Although there may be some exceptions, as a general rule it is assumed that from a user point of view, a prime requirement for any data transfer application is to guarantee essentially zero loss of information. At the same time, delay variation is not applicable. The different applications therefore tend to distinguish themselves on the basis of the delay which can be tolerated by the end-user from the time the source content is requested until it is presented to the user. Web-browsing In this category we will refer to retrieving and viewing the HTML component of a Web page, other components eg images, audio/video clips are dealt with under their separate categories. From the user point of view, the main performance factor is how fast a page appears after it has been requested. A value of 2-4 seconds per page is proposed, however improvement on these figures to a target figure of 0.5 seconds wound be desirable. High-priority transaction services (E-commerce) The main performance requirement here is to provide a sense of immediacy to the user that the transaction is proceeding smoothly. A value of 2-4 seconds is suggested to be acceptable to most users. E-mail (server access) E-mail is generally thought to be a store and forward service which in principle can tolerate delays of several minutes or even hours. However, it is important to differentiate between communications between the user and the local email server and server to server transfer. When the user communicates with the local mail server, there is an expectation that the mail will be transferred quite rapidly, although not necessarily instantaneously. Consistent with the research findings on delay tolerance for Web-browsing, a requirement of 2-4 seconds is proposed.

When the user is looking at (listening to) video (audio) the scheme streams applies. The real time data flow is always aiming at a live (human) destination. It is a one way transport. This scheme is one of the newcomers in data communication, raising a number of new requirements in both telecommunication and data communication systems. First of all it is a mainly unidirectional stream with high continuous utilisation (i.e. having few idle/silent periods.) It is also characterised by that the time relations (variation) between information entities (i.e. samples, packets) within a flow must be preserved, although it does not have any requirements on low transfer delay. The delay variation of the end-to-end flow must be limited, to preserve the time relation (variation) between information entities of the stream. But as the stream normally is time aligned at the receiving end (in the user equipment), the highest acceptable delay variation over the transmission media is given by the capability of the time alignment function of the application. Acceptable delay variation is thus much greater than the delay variation given by the limits of human perception. Real time streams - fundamental characteristics for QoS:

• unidirectional continuous stream
• preserve time relation (variation) between information entities of the stream

The resulting overall requirement for this communication scheme is to support streaming real time services having unidirectional data flows with continuous utilisation. (There are less stringent requirements on delay and packet loss ratio, i.e. the ratio of lost or corrupted packets out of all packets sent.) Audio streaming Audio streaming is expected to provide better quality than conventional telephony, and requirements for information loss in terms of packet loss will be correspondingly tighter. However, as with voice messaging, there is no conversational element involved and delay requirements can be relaxed, even more so than for voice-messaging. One-way video The main distinguishing feature of one-way video is that there is no conversational element involved, meaning that the delay requirement will not be so stringent, and can follow that of streaming audio. Bulk data This category includes file transfers, and is clearly influenced by the size of the file. As long as there is an indication that the file transfer is proceeding, it is reasonable to assume some what longer tolerance to delay than for a single Web-page. Still image This category includes a variety of encoding formats, some of which may be tolerant to information loss since they will be viewed by a human eye. However, given that even single bit errors can cause large disturbances in other still image formats, it is argued that this category should in general have zero information loss. However, delay requirements for still image transfer are not stringent, given that the image tends to be built up as it is being received, which provides an indication that data transfer is proceeding. Telemetry (monitoring) Monitoring covers a wide range of applications, but in this category it is taken to apply to relatively low priority activities, e.g. status updating, rather than control.

When the end-user, that typically is a computer, sends and receives data-files in the background, this scheme applies. Examples are background delivery of E-mails, SMS, download of databases and reception of measurement records. Background traffic is one of the classical data communication schemes that on an overall level is characterised by that the destination is not expecting the data within a certain time. The scheme is thus more or less delivery time insensitive. Another characteristic is that the content of the packets must be transparently transferred (with low bit error rate). Background traffic - fundamental characteristics for QoS:

• the destination is not expecting the data within a certain time
• preserve payload content

The resulting overall requirement for this communication scheme is to support non-real time services without any special requirement on delay. A background application is one that does not carry delay information. In principle, the only requirement for applications in this category is that information should be delivered to the user essentially error free. However, there is still a delay constraint, since data is effectively useless if it is received too late for any practical purpose. Fax Fax is included in this category since it is not normally intended to be an accompaniment to real-time communication. Nevertheless, there is an expectation in most business scenarios that a fax will be received within about 30 seconds. The information loss requirement is based on established wireline requirements for a Group 3 fax. As for the symmetry this should provide the required through put in the sending direction and the control signalling in backwards direction, hence an asymmetric connection is required. Low priority transaction services An example in this category is Short Message Service (SMS). 30 seconds is proposed as an acceptable delivery delay value. Email (server to server) This category is included for completeness, since as mentioned earlier, the prime interest in email is in the access time. There is a wide spread in user expectation, with a median value of several hours.