Project IEEE 802.20 Working Group on Mobile Broadband Wireless Access <http://grouper.ieee.org/groups/802/20/>

Title A new option proposed for 802.20 requirements on latency and packet error rates

Date Submitted

2004-05-10

Source(s) Anna Tee 1301 E Lookout Dr.,Richardson, TX 75082

Voice: (972) 761-7437Fax: (972) 761-7909Email: atee@sta.samsung.com

Joseph Cleveland 1301 E Lookout Dr.,Richardson, TX 75082

Voice: (972) 761-7981Fax: (972) 761-7909Email: jclevela@sta.samsung.com

Re: MBWA Call for Contributions, Session #8, May 2004

Abstract This is a contribution to the requirements on latency and packet error rate for the IEEE 802.20 system requirements document. A new, revised option is proposed with reference to similar requirements used in other wireless communication standards.

Purpose For discussion and adoption into IEEE 802.20 System Requirements Document.

Notice This document has been prepared to assist the IEEE 802.20 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

Release The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.20.

Patent Policy The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development <http://standards.ieee.org/board/pat/guide.html>.

A new option proposed for 802.20 A new option proposed for 802.20 requirements on latency and packet requirements on latency and packet

error rateserror rates

Anna TeeAnna TeeJoseph ClevelandJoseph Cleveland

May 10, 2004May 10, 2004

TopicsTopics

Effects of Wireless link on TCP performance Effects of Wireless link on TCP performance Error rate requirements in some current standards Error rate requirements in some current standards Latency or Packet Transfer Delay Latency or Packet Transfer Delay End user QoS categories recommended by ITU-TEnd user QoS categories recommended by ITU-T Traffic classification by 3GPPTraffic classification by 3GPP IETF QoS classification IETF QoS classification Propose requirements for 802.20Propose requirements for 802.20 ReferencesReferences

Effects of Wireless Link on TCP performanceEffects of Wireless Link on TCP performance

Performance of TCP throughput over wireless links Performance of TCP throughput over wireless links deteriorates significantly because of errors caused by the deteriorates significantly because of errors caused by the wireless link [1] wireless link [1]

For example, IEEE 802.11b TCP throughput is only 4.3 Mbps, For example, IEEE 802.11b TCP throughput is only 4.3 Mbps, even the physical bit rate is 11 Mbps, i.e., only 39.1% of the even the physical bit rate is 11 Mbps, i.e., only 39.1% of the maximum data rate is achieved maximum data rate is achieved

Packet losses in the link can trigger triple-duplicate Packet losses in the link can trigger triple-duplicate acknowledgements and time-out mechanisms acknowledgements and time-out mechanisms

TCP behavior such as congestion avoidance, slow-start affects TCP behavior such as congestion avoidance, slow-start affects TCP throughput TCP throughput

The PFTK model [3] is a model for the TCP Reno congestion The PFTK model [3] is a model for the TCP Reno congestion avoidance mechanism for bulk transfer packet flows.avoidance mechanism for bulk transfer packet flows.

TCP Throughput Variation with TCP Throughput Variation with Packet Loss Rate & Round Trip DelayPacket Loss Rate & Round Trip Delay

TCP throughput based on PFTK model computed for ranges of packet TCP throughput based on PFTK model computed for ranges of packet loss rates and round trip delays loss rates and round trip delays

Maximum window size: 123 segments; maximum segment size (MSS): Maximum window size: 123 segments; maximum segment size (MSS): 536 bytes 536 bytes

TCP throughput decreases significantly as the packet loss rate TCP throughput decreases significantly as the packet loss rate increases beyond 10increases beyond 10-4-4

At low packet loss rates, the TCP throughput decreases rapidly as the At low packet loss rates, the TCP throughput decreases rapidly as the values of round-trip delay (RTD) increases. As the packet loss rate values of round-trip delay (RTD) increases. As the packet loss rate increases, it becomes the limiting factor for the TCP throughput, even increases, it becomes the limiting factor for the TCP throughput, even when RTD is low. when RTD is low.

Packet loss rate should be better than 10Packet loss rate should be better than 10-4-4 while keeping the RTD as while keeping the RTD as low as possible for the best performance in terms of TCP throughput. low as possible for the best performance in terms of TCP throughput.

Effects of Packet Loss Rate Effects of Packet Loss Rate with Round Trip Delay as a Parameterwith Round Trip Delay as a Parameter

Effects of Round Trip DelayEffects of Round Trip Delay

Error Rate Requirements in Current Error Rate Requirements in Current StandardsStandards

““Network performance objectives for IP-based services”: ITU-T Y.1541Network performance objectives for IP-based services”: ITU-T Y.1541 Parameters that are used in Y.1541 [4] are defined in ITU-T Y.1540 [5]Parameters that are used in Y.1541 [4] are defined in ITU-T Y.1540 [5]

IP packet transfer delay (IPTD) IP packet transfer delay (IPTD) IP packet delay variation (IPDV) IP packet delay variation (IPDV) IP packet loss ratio (IPLR) IP packet loss ratio (IPLR) IP packet error ratio (IPER) IP packet error ratio (IPER)

Six different classes of traffic based on IPTD and IPDV objectives Six different classes of traffic based on IPTD and IPDV objectives All specified values are provisional, upper bounds All specified values are provisional, upper bounds

Network Performance Network Performance ParameterParameter

Class 0Class 0 Class 1Class 1 Class 2Class 2 Class 3Class 3 Class 4Class 4 Class 5Class 5

IPTDIPTD 100 ms100 ms 400 ms400 ms 100 ms100 ms 400 ms400 ms 1 s1 s U*U*

IPDVIPDV 50 ms50 ms 50 ms50 ms UU UU UU UU

IPLRIPLR 1x101x10-3-3 UU

IPERIPER 1x101x10-4-4 UU

*U: Unspecified

IEEE STD. 802-2001IEEE STD. 802-2001

““IEEE standard for local and metropolitan area networks: Overview and IEEE standard for local and metropolitan area networks: Overview and Architecture” [6]Architecture” [6] Defines the compliance with the family of IEEE 802 StandardsDefines the compliance with the family of IEEE 802 Standards Describes & explains relationship of the IEEE 802 standards to the OSI Describes & explains relationship of the IEEE 802 standards to the OSI

Basic Reference Model and Higher Layer protocolsBasic Reference Model and Higher Layer protocols

Subsection 7.3 of IEEE Std. 802-2001 states that:Subsection 7.3 of IEEE Std. 802-2001 states that: Required error performance of IEEE 802 LANs and MANs shall be less than Required error performance of IEEE 802 LANs and MANs shall be less than

8x108x10-8-8 per octet of MAC service Data unit (MSDU) length. While this error per octet of MAC service Data unit (MSDU) length. While this error performance has to be accomplished at the physical layer for wired or optical performance has to be accomplished at the physical layer for wired or optical fiber physical media, it is allowable for this error performance to be fiber physical media, it is allowable for this error performance to be accomplished at the MAC service boundary in the case of wireless media.accomplished at the MAC service boundary in the case of wireless media.

For example: MSDU packet with 1500 octets,For example: MSDU packet with 1500 octets, Required packet error rate => 1.2x10Required packet error rate => 1.2x10-4-4

Value agrees closely with the IPER requirement specified in ITU-T Y.1541, Value agrees closely with the IPER requirement specified in ITU-T Y.1541, in the case of ~1 MSDU / IP Packetin the case of ~1 MSDU / IP Packet

Requirements on Error Rates Requirements on Error Rates in IEEE 802.16.3 [7]in IEEE 802.16.3 [7]

ServiceService Maximum BERMaximum BER Maximum Access Delay Maximum Access Delay (One-Way)(One-Way)

Full Quality TelephonyFull Quality Telephony

(Vocoder MOS >= 4.0)(Vocoder MOS >= 4.0)

1010-6-6 20 ms20 ms

Standard Quality Telephony Standard Quality Telephony (Vocoder MOS < 4.0)(Vocoder MOS < 4.0)

1010-4-4 40 ms40 ms

Time Critical Packet ServicesTime Critical Packet Services 1010-6-6 20 ms20 ms

Non-Time Critical ServicesNon-Time Critical Services 1010-9-9 Not applicableNot applicable

Assuming bit errors are independent, for BER = 10-9, => Octet error rate ~ 8 x 10-9

10 times more stringent than Std. 802-2001 requirement

Thus, for a MSDU with 1500 octets, the packet error rate, assuming independent octet errors, is approximately:

5

9

102.1

1081500

PER

Error Rate Performance Supported by 3GPPError Rate Performance Supported by 3GPP

Ranges of BER that the network is required to support [8]: 10-3 to 10-7 for real time applications 10-5 to 10-8 for non-real time applications

Assuming bit errors are independent, for BER = 10-8,

=> Octet error rate ~ 8 x 10-8

Similar to Std. 802-2001 requirement

Thus, for a MSDU with 1500 octets, the packet error rate, assuming independent octet errors, is approximately

4

8

102.1

1081500

PER

Error Rate Performance in some Existing Error Rate Performance in some Existing Cellular Communication NetworksCellular Communication Networks

Error rate performance of GSM as reported in [1] can support a bit Error rate performance of GSM as reported in [1] can support a bit error ratio of 10error ratio of 10-3-3, which is then reduced to 10, which is then reduced to 10-8-8 in the in the nontransparent mode RLP, at the expense of variable, additional nontransparent mode RLP, at the expense of variable, additional delay due to retransmissions, reducing the user throughput. delay due to retransmissions, reducing the user throughput.

In IS-95 standard, frames are dropped after undergoing repeated In IS-95 standard, frames are dropped after undergoing repeated retransmissions a number of times to limit the delay variation. The retransmissions a number of times to limit the delay variation. The residual packet loss rate becomes 10residual packet loss rate becomes 10-4-4. .

Video over IP Error Rate RequirementsVideo over IP Error Rate Requirements For real-time video signal, ITU-T SG13 has recommended that For real-time video signal, ITU-T SG13 has recommended that

IPLR must be at least 10IPLR must be at least 10-5-5 [10] [10] Derived based on a BER of 10Derived based on a BER of 10-9-9 for typical fiber optic network for typical fiber optic network Worst-case assumptions:Worst-case assumptions:

1.1. Packet size = 1500 bytes Packet size = 1500 bytes 2.2. A bit error caused the whole packet to be lostA bit error caused the whole packet to be lost

User Datagram Protocol (UDP): used for transport of most video User Datagram Protocol (UDP): used for transport of most video streaming applicationsstreaming applications

UDP checksum is enabled UDP checksum is enabled => => AA packet may be discarded because of a single bit error packet may be discarded because of a single bit error UDP does not allow a re-transmission of the lost packet, the effects of UDP does not allow a re-transmission of the lost packet, the effects of

losing a complete video packet could result in serious disruption to losing a complete video packet could result in serious disruption to the video signalthe video signal

UDP checksum is normally disabled in most applicationsUDP checksum is normally disabled in most applications Packets with bit errors will be received including the error bits Packets with bit errors will be received including the error bits Depending on the location of the error bits, the effects of the lost may Depending on the location of the error bits, the effects of the lost may

be tolerable to the user at the receiving endbe tolerable to the user at the receiving end

Performance Requirements for Real-time Performance Requirements for Real-time Conversational Class - VoiceConversational Class - Voice

Conversational VoiceConversational Voice

Acceptable maximum FER = 3%Acceptable maximum FER = 3%

General limits for one-way end-to-end delay as recommended by G.114: General limits for one-way end-to-end delay as recommended by G.114: 0 - 150 ms - preferred range0 - 150 ms - preferred range 150 - 400 ms - acceptable range with increasing degradation150 - 400 ms - acceptable range with increasing degradation

Requirement is also dependent on the error resilience of speech codec. For Requirement is also dependent on the error resilience of speech codec. For AMR speech codec: [9]AMR speech codec: [9]

Bit rate: 4.75 - 12.2 kbpsBit rate: 4.75 - 12.2 kbps Required BER: Required BER:

1010-4-4 for Class 1 bits, 10 for Class 1 bits, 10-3-3 for Class 2 bits, a higher BER class at 10 for Class 2 bits, a higher BER class at 10 -2-2 might might also be feasible. also be feasible.

With codec frame length of 20 ms, the one-way end-to-end delay should be With codec frame length of 20 ms, the one-way end-to-end delay should be less than 100ms. less than 100ms.

Performance Requirements for Real-time Performance Requirements for Real-time Conversational Class - OthersConversational Class - Others

VideophonesVideophones Delay requirement: similar to conversational voice, with additional requirement Delay requirement: similar to conversational voice, with additional requirement

on limits of lip-synchon limits of lip-synch Maximum acceptable FER: 1%Maximum acceptable FER: 1%

Interactive gamesInteractive games One-way delay value of 250 ms proposed in [8]One-way delay value of 250 ms proposed in [8] Detail studies on multiplayer network gaming reported [11] the range of Detail studies on multiplayer network gaming reported [11] the range of

acceptable maximum round-trip time: 200 ms - 40 seconds, depending on the acceptable maximum round-trip time: 200 ms - 40 seconds, depending on the type of games, experience level of playerstype of games, experience level of players

Gaming can be : Conversational, Interactive or Interactive/BackgroundGaming can be : Conversational, Interactive or Interactive/Background Proposed residual BER requirement: 10Proposed residual BER requirement: 10-3-3, 10, 10-5 -5 / 6x10/ 6x10-8-8, or 10, or 10-5 -5 / 6x10/ 6x10-8-8 respectively respectively Proposed maximum one-way delay for the action game: 80ms. Proposed maximum one-way delay for the action game: 80ms.

Two-way control telemetryTwo-way control telemetry One-way delay limit: 250 ms proposed in [8]One-way delay limit: 250 ms proposed in [8] ““0” information loss 0” information loss

Performance Requirements for Performance Requirements for Interactive ClassInteractive Class

Voice messaging:Voice messaging: Similar error rate requirement as that of conversational classSimilar error rate requirement as that of conversational class Delay: up to a few secondsDelay: up to a few seconds

Web Browsing:Web Browsing: Delay requirement: 2 - 4 seconds/pageDelay requirement: 2 - 4 seconds/page Recommended to improve to 0.5 secondRecommended to improve to 0.5 second

High priority transaction services - E-commerce:High priority transaction services - E-commerce: Delay: 2 - 4 secondsDelay: 2 - 4 seconds Information loss: “0”Information loss: “0”

Email:Email: Server to Server delay: several minutes or hoursServer to Server delay: several minutes or hours User to local server delay: 2-4 secondsUser to local server delay: 2-4 seconds

Performance Requirements for Performance Requirements for Streaming Class – Audio/VideoStreaming Class – Audio/Video

Audio streaming:Audio streaming: mainly an one-way application from server to user (s) mainly an one-way application from server to user (s) Contents of the audio stream: high quality music or broadcastingContents of the audio stream: high quality music or broadcasting Packet Loss rate requirement: 1% [13]Packet Loss rate requirement: 1% [13] Delay requirement: one-way delay = 10 seconds Delay requirement: one-way delay = 10 seconds

Video streaming:Video streaming: Similar to audio streaming as described above Similar to audio streaming as described above MPEG-4 video: [9]MPEG-4 video: [9]

Bit rate: 24 - 128 kbps or higherBit rate: 24 - 128 kbps or higher End-to-end delay: 150 - 400msEnd-to-end delay: 150 - 400ms BER: 10BER: 10-6-6 - 10 - 10-3-3 with significant degradation for the latter with significant degradation for the latter

Still image:Still image: Similar requirements to Video StreamingSimilar requirements to Video Streaming Error tolerance: dependent on the encoding and compression formatsError tolerance: dependent on the encoding and compression formats

Performance Requirements for Performance Requirements for Streaming Class - DataStreaming Class - Data

Bulk Data Transfer (File Transfers):Bulk Data Transfer (File Transfers): May be classified as streaming service with relaxed delay toleranceMay be classified as streaming service with relaxed delay tolerance ““0” final information loss at the receiving end 0” final information loss at the receiving end

Telemetry applications (Monitoring)Telemetry applications (Monitoring) Error rate and delay requirements: similar to that of the bulk data transferError rate and delay requirements: similar to that of the bulk data transfer

Performance Requirements for Performance Requirements for Background ClassBackground Class

No stringent requirement on delay for the background class of servicesNo stringent requirement on delay for the background class of services

Requirements for Fax:Requirements for Fax: Delay: 30 secondsDelay: 30 seconds BER: less than 10BER: less than 10-6-6 [13] [13]

Low priority transaction servicesLow priority transaction services Short message services (SMS)Short message services (SMS) Delivery delay: 30 secondsDelivery delay: 30 seconds Email:Email:

Server to server delay: wide range with median of several hoursServer to server delay: wide range with median of several hours

Latency or Packet Transfer DelayLatency or Packet Transfer Delay

ITU-T Y.1541 Model: Hypothetical Reference Path for Transfer Delay ITU-T Y.1541 Model: Hypothetical Reference Path for Transfer Delay and Delay Variation Computationand Delay Variation Computation

Path analysis for IPTD & IPDV in an IP networkPath analysis for IPTD & IPDV in an IP network End-to-end One Way Transfer Delay = Path Delay + End-point Delay End-to-end One Way Transfer Delay = Path Delay + End-point Delay

TE TEGW . . . . . .

Network Section

End-End Network (Bearer Service QOS)

Network Section Network Section

Customer Installation Customer Installation

User-to-User Connection (Teleservice QOS)

TE GWTerminal Equipment Router Protocol Stack

LAN LAN

IP Network Cloud

NI NI

NI Network Interface

GW GW GW GW GW

Path Delay & Variation Analysis ExamplePath Delay & Variation Analysis Example ITU-T Y.1541 QoS Class 0 ITU-T Y.1541 QoS Class 0 US Diagonal path: Daytona Beach to SeattleUS Diagonal path: Daytona Beach to Seattle

Element Unit IPTD/unit

AveIPTD

IPDV/unit

Max IPDV

Distance 4070 km

Route 5087.5 km 25

Insertion Time 200 bytes (VoIP)(1500 bytes)

1(8)

Non IP Net 1 15 0

IP Net 1

Access, NA 1 10 10 16 16

Distribution, ND 1 3 3 3 3

Core, NC 2 2 4 3 6

Internetwork GW, NI 1 3 3 3 3

IP Net 2

Access, NA 1 10 10 16 16

Distribution, ND 1 3 3 3 3

Core, NC 4 2 8 3 12

Internetwork GW, NI 1 3 3 3 3

Non IP Net 2 15 0

Total, ms 100 62

Statistics of Internet delayStatistics of Internet delay

Earlier studies presented in IETF [12] showed that the probability Earlier studies presented in IETF [12] showed that the probability distribution function of one-way Internet delay is the shifted Gamma distribution function of one-way Internet delay is the shifted Gamma distributiondistribution

Mean delay values - Mean delay values - Local routes: 10 msLocal routes: 10 ms International routes: 110 msInternational routes: 110 ms

Sprint’s Looking Glass toolsSprint’s Looking Glass tools Delay -Delay -

Within the same state: ~ 20 msWithin the same state: ~ 20 ms Between East and West coasts: ~ 40 msBetween East and West coasts: ~ 40 ms Between West coast and Asia: ~ 200ms Between West coast and Asia: ~ 200ms

One-way Delay & RTDOne-way Delay & RTD

Overall one way delay in the mobile network from user equipment Overall one way delay in the mobile network from user equipment (UE) to the public land mobile network (PLMN) border: ~ 100 ms [8](UE) to the public land mobile network (PLMN) border: ~ 100 ms [8]

For a single user link, RTD of 10 ms is ideal in order to achieve TCP For a single user link, RTD of 10 ms is ideal in order to achieve TCP throughput of about 40 Mbps at IPLR of 10throughput of about 40 Mbps at IPLR of 10-4-4, based on results of , based on results of PFTK modelPFTK model

RTD = 10 ms may not be realistic in practice due to constraints on the RTD = 10 ms may not be realistic in practice due to constraints on the PHY and MAC layers, fairness considerations in the scheduling PHY and MAC layers, fairness considerations in the scheduling algorithm in a multiple access network etc. algorithm in a multiple access network etc.

Delay in IP network as discussed in the above section showed that it Delay in IP network as discussed in the above section showed that it is almost impossible for RTD to be 10 ms or lessis almost impossible for RTD to be 10 ms or less

End User QoS Categories as End User QoS Categories as Recommended by ITU-T G.1010Recommended by ITU-T G.1010

Class Interactive Responsive Timely Non-critical

Delay << 1 sec ~ 2 sec ~ 10 sec >> 10 sec

0%

Packet Loss

Command/ control

(eg Telnet,Interactive

games)

Conversationalvoice and video

Voice/videomessaging

Streamingaudio/video

Transactions(eg E-commerce,Web-browsing, E-

mail access)

Messaging,Downloads

(eg FTP,still image)

Fax

Background(eg Usenet)

5%

100 msec 1 sec 10 sec 100 sec

Zeroloss

Delay

Applications & Services Classification by 3GPPApplications & Services Classification by 3GPP

Class Conversational Streaming Interactive Background

Delay <= 80 ms <= 250 ms unspecified unspecified

Residual BER 5x10-2, 10-2, 5x10-3, 10-3, 10-4, 10-5 ,10-6 4x10-3, 10-5 , 6x10-8

SDU error ratio 10-1, 10-2, 7x10-3, 10-3, 10-4, 10-5 10-3, 10-4 , 10-6

• Similar to ITU-T, services are classified into 4 classes based on the their one-way delay requirements

• Within each service class, a range of residual BER and SDU error ratio are supported

IETF QoS ClassificationIETF QoS Classification

Service Class DSCP name Application Example

Administrative CS7 Heartbeats

Network Control CS6 Network Routing

Telephony EF, CS5 IP Telephony

Multimedia Conferencing AF41-AF43 Video Conferencing, Interactive Gaming

Multimedia Streaming AF31-AF33, CS4 Broadcast TV, Pay per View, Video Surveillance

Low Latency Data AF21-AF23, CS3 Client/Server transactions, peer-to-peer signaling

High Throughput Data AF11-AF13, CS2 Store & Forward applications, Non-critical OAM&P

Standard DF (CS0) Undifferentiated applications

Low Priority Data CS1 Any flow that has no BW assurance

• “9” Service Classes are defined and mapped to DiffServ Code Points (DSCP) [14]

• ITU-T Y.1541, ITU-T Y.1540 and G.1010 considered

Propose Requirements for 802.20Propose Requirements for 802.20 4.1.7 4.1.7 Latency and Packet Error RateLatency and Packet Error Rate

The system shall support a variety of traffic classes with different latency and packet error rates performance, in order to meet the end-user QoS requirements for the various applications, as recommended by ITU G.1010, Y.1541. These traffic classes should be mapped to the appropriate QoS classes as defined for the QoS architecture described in Section 4.4.1. Depending on the network configuration, the AI should support appropriate latency and packet error rate performance targets associated with each traffic class, such that the end-to-end QoS requirements for these applications can be achieved. In the case of IETF DiffServ, the requirements for the AI are shown in the following table.

The numbers quoted in the table use the following assumptions: 1. MAC SDU size = 1500 bytes2. Network Delay = 20 ms, 100 ms3. Size of IP packet: 1 MAC SDU / IP packet4. For UDP and very low-latency TCP traffic:

End-to-end One-way Delay ≈ 802.20 Latency + Network Delay

IETF Service class Transport Protocol

End-to-end One way Delay (s)

Network Delay (ms)

802.20Delay (ms)

MAC SDU Packet Error

Rate

IP Packet Error Rate

Administrative TCP 0.10 20 20 10-6 10-6

Network Control [8,9,13]

TCP 0.25 20 30 10-6 10-6

Telephony [8,13]

(Voice over IP)

UDP/ RTP 0.15 100 50 3 x 10-2 3 x 10-2

Multimedia Conferencing

[8,13]

UDP/ RTP 0.15 100 50 10-2 10-2

Multimedia Streaming [8,13]

UDP/ RTP 5 100 200 10-2 10-2

Low Latency Data [8,13]

(E-transactions)

TCP 2 20 30 10-5 10-5

High Throughput Data (Email)

[4,8,9,13]

TCP 6* 20 30 10-4 10-4

Standard(FTP) [4,8,9,13]

TCP 10* 20 50 10-4 10-4

Low Priority Data [4,8,9,13]

TCP 100 100 100 10-3 10-3

*Time required to transfer all the packets for the email or file.

ReferencesReferences1.1. G. Xylomenos, F. Polyzos, P. Mahonen, M. Saaranen, ‘TCP Performance Issues over G. Xylomenos, F. Polyzos, P. Mahonen, M. Saaranen, ‘TCP Performance Issues over

Wireless Links’, IEEE communicatWireless Links’, IEEE communications Magazine, April 2001.'ions Magazine, April 2001.'2.2. C802.20-04-29, Contribution to 802.20 Plenary meeting, March 2004.C802.20-04-29, Contribution to 802.20 Plenary meeting, March 2004.3.3. J. Padhye, V. Firoiu, D. Towsley, J. Kurose, “Modeling TCP Reno Performance: A Simple J. Padhye, V. Firoiu, D. Towsley, J. Kurose, “Modeling TCP Reno Performance: A Simple

Model and Its Empirical Validation”, IEEE/ACM Trans. On Networking, Vol. 8, No.2, April Model and Its Empirical Validation”, IEEE/ACM Trans. On Networking, Vol. 8, No.2, April 2000. 2000.

4.4. ““Network performance objectives for IP-based services”, ITU-T Y.1541, May 2002.Network performance objectives for IP-based services”, ITU-T Y.1541, May 2002.5.5. ““Internet Protocol Data Communication Service – IP packet transfer and availability Internet Protocol Data Communication Service – IP packet transfer and availability

performance parameters”, ITU-T Y.1540, Jan 2002.performance parameters”, ITU-T Y.1540, Jan 2002.6.6. ““IEEE Standard for local and metropolitan area networks: Overview and Architecture”, IEEE IEEE Standard for local and metropolitan area networks: Overview and Architecture”, IEEE

Std. 802-2001, March 8, 2002.Std. 802-2001, March 8, 2002.7.7. ““Functional Requirements for the 802.16.3 Interoperability Standard”, IEEE 802.16.3-Functional Requirements for the 802.16.3 Interoperability Standard”, IEEE 802.16.3-

00/02r4, September 22, 2000. 00/02r4, September 22, 2000. 8.8. 3GPP TS 22.105 V 6.2.0 (2003-06), Technical Specification Group Services and Systems 3GPP TS 22.105 V 6.2.0 (2003-06), Technical Specification Group Services and Systems

Aspects, Service Aspects; Services and Services Capabilities.Aspects, Service Aspects; Services and Services Capabilities.9.9. 3GPP TS 23.107 V 5.10.0 (2003-09), Technical Specification Group Services and Systems 3GPP TS 23.107 V 5.10.0 (2003-09), Technical Specification Group Services and Systems

Aspects, Service Aspects; QoS concept and architecture (Release 5).Aspects, Service Aspects; QoS concept and architecture (Release 5).10.10. Video Performance requirements for IP performance recommendations, ITU-T SG13 D.228 Video Performance requirements for IP performance recommendations, ITU-T SG13 D.228

(WP4/13), Jan 14, 2002.(WP4/13), Jan 14, 2002.11.11. Multiplayer Game Performance over Cellular Networks, V1.0, Forum Nokia, Jan 20, 2004Multiplayer Game Performance over Cellular Networks, V1.0, Forum Nokia, Jan 20, 200412.12. Statistics of One-Way Internet Packet Delays, A. Corlett, D. Pullin, S. Sargood, 53rd IETF, Statistics of One-Way Internet Packet Delays, A. Corlett, D. Pullin, S. Sargood, 53rd IETF,

March 18, 2002.March 18, 2002.13.13. ITU G.1010 [“Draft New Recommendation G.QoSRQT – End-user Multimedia QoS ITU G.1010 [“Draft New Recommendation G.QoSRQT – End-user Multimedia QoS

Categories”, ITU-T study group 12, contribution 37, August 2001]Categories”, ITU-T study group 12, contribution 37, August 2001]14.14. F. Baker et. al., IETF Draft “Configuration Guidelines for DiffServ Service Classes draft-F. Baker et. al., IETF Draft “Configuration Guidelines for DiffServ Service Classes draft-

baker-diffserv-basic-classes-02”, Feb 13, 2004.baker-diffserv-basic-classes-02”, Feb 13, 2004.15.15. 802.20 Evaluation Criteria, Draft ver. 0.9, May 5, 2004.802.20 Evaluation Criteria, Draft ver. 0.9, May 5, 2004.