ATIS T1 TR 66-2001 Technical Report on Requirements for Wireless Internet Protocol (IP) Telephony.pdf

《ATIS T1 TR 66-2001 Technical Report on Requirements for Wireless Internet Protocol (IP) Telephony.pdf》由会员分享，可在线阅读，更多相关《ATIS T1 TR 66-2001 Technical Report on Requirements for Wireless Internet Protocol (IP) Telephony.pdf（30页珍藏版）》请在麦多课文档分享上搜索。

1、 Problem Solvers to the Telecommunications Industry TECHNICAL REPORT T1.TR.66-2001 Technical Report on Requirements for Wireless Internet Protocol (IP) Telephony Prepared by T1P1.5 Working Group on Personal Communications Service A Word from ATIS and Committee T1 Established in February 1984, Commit

2、tee T1 develops technical standards, reports and requirements regarding interoperability of telecommunications networks at interfaces with end-user systems, carriers, information and enhanced-service providers, and customer premises equipment (CPE). Committee T1 is sponsored by ATIS and is accredite

3、d by ANSI. T1.TR.66-2001 Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, Suite 500 Washington, DC 20005 Committee T1 is sponsored by the Alliance for Telecommunications Industry Solutions (ATIS) and accredited by the American National Standards Institute (ANSI). Co

4、pyright 2001 by Alliance for Telecommunications Industry Solutions All rights reserved. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. For information contact ATIS at 202.628.6380. ATIS

5、 is online at . Printed in the United States of America. T1.TR.66-2001 Requirements for Wireless Internet Protocol (IP) Telephony ABSTRACT This technical report summarizes Committee T1s current view on the requirements for Wireless Internet Protocol Telephony and identifies some of the issues involv

6、ed in extending the existing GPRS network to support an IP-based telephony (voice) service. Document T1P1.5/2000-096r2 Prepared by T1P1.5 Working Group on Personal Communications Service T1.TR.66-2001 ii TABLE OF CONTENTS 1 SCOPE . 2 2 REFERENCES . 2 3 DEFINITIONS . 3 4 ABBREVIATIONS 3 5 INTRODUCTIO

7、N 4 6 BACKGROUND/BUSINESS DRIVERS. 4 7 GPRS PHASE 1 ARCHITECTURE 5 8 IP TELEPHONY REQUIREMENTS . 7 8.1 SERVICES 8 8.2 SPEECH 8 8.3 DATA. 8 8.4 FACSIMILE . 8 8.5 SUPPLEMENTARY SERVICES. 8 8.6 ADDITIONAL SERVICES. 8 9 NETWORK CAPABILITIES . 9 9.1 TERMINAL ADDRESSING . 9 9.2 ROAMING 9 9.3 SERVICE CONTR

8、OL 9 9.4 SERVICE PORTABILITY . 9 9.5 PSTN INTEROPERABILITY 9 9.6 WIRELESS CS DOMAIN INTEROPERABILITY . 9 9.7 OPEN INTERFACES. 9 9.8 RELIABILITY AND AVAILABILITY 9 9.9 SERVICE DIFFERENTIATION 9 9.10 QUALITY OF SERVICE . 10 9.11 CHARGING. 10 9.12 OPERATIONS, ADMINISTRATION AND MAINTENANCE. 10 10 AIR I

9、NTERFACE CONSIDERATIONS. 10 10.1 PHYSICAL LAYER 10 10.2 DATA LINK LAYER. 10 10.3 MEDIUM ACCESS CONTROL (MAC) LAYER 11 10.4 LOGICAL LINK CONTROL (LLC) . 11 11 QUALITY OF SERVICE (QOS) 13 11.1 INTRODUCTION TO QOS 13 11.1.1 END-TO-END DELAY . 13 11.1.2 DELAY JITTER 14 11.1.3 THROUGHPUT 14 11.1.4 RELIAB

10、ILITY . 15 11.1.5 AVAILABILITY 15 11.2 QOS REQUIREMENTS. 15 11.2.1 REAL-TIME VOICE. 15 T1.TR.66-2001 iii 11.2.2 INTERACTIVE DATA. 16 11.2.3 DATA RETRIEVAL (BULK DATA TRANSFER) 16 11.3 GPRS QOS 16 11.3.1 PRIORITY LEVELS. 16 11.3.2 RELIABILITY CLASS. 17 11.3.3. DELAY CLASS. 17 11.3.4 THROUGHPUT CLASS

11、. 18 11.4 OBSERVATIONS/ISSUES 19 12 CURRENT RELEVANT STANDARDS ACTIVITIES . 19 12.1 3GPP . 20 12.2 ITU-T 20 12.2.1 RECOMMENDATION H.323 20 12.3 IETF . 22 12.3.1 SESSION INITIATION PROTOCOL (SIP). 22 12.4 ETSI . 23 12.4.1 TIPHON . 23 13 CONCLUSIONS 24 TABLE OF FIGURES Figure 1: GPRS Physical Architec

12、ture. 6 Figure 2: GPRS Transmission plane reference model 7 Figure 3: H.323 Architecture 21 TABLE OF TABLES Table 1: Comparison of header size12 Table 2: Reliability classes. 17 Table 3: Delay classes. 18 Table 4: Peak Throughput Classes . 18 Table 5: Mean Throughput Classes. 19 T1.TR.66-2001 iv Thi

13、s Technical Report (TR) was developed in Technical Subcommittee T1P1 on Wireless/Mobile Services and Systems. A. Chatterjee, T1P1 Chair M. Younge, T1P1 Vice Chair Q. Cassen, T1P1 Secretary C. Campbell, T1P1 Technical Editor C. Underkoffler, T1 Chief Editor Working Group T1P1.5 developed this TR. Ove

14、r the course of its development, the following individuals participated in the Working Groups discussions and made significant contributions to the standard: Bob Beeson Lucent Technologies Clif Campbell SBC Technology Resources/Pacific Bell Wireless Quent Cassen Conexant Asok Chatterjee Ericsson Ed

15、Ehrlich Nokia Rouzbeh Farhoumand Ericsson Christopher J. Fitzgerald Defense Information Systems Agencies Andrew Gallant Comsat Robert Hall SBC Technology Resources/SBC Majeed Kamdar Siemens Gil LaVean Interdigital George Lynch Aerial John Menard Lucent Technologies Nagarao Rao Siemens Brian Roan Nok

16、ia Gary Schlanger AT - random access; - demand-based assignment. With fixed assignments, each user is allowed access to a predetermined and fixed allocation of resources regardless of the users need to transmit data. This scheme is appropriate for continuous traffic such as bulk data transfer but in

17、efficient for bursty type traffic. This is very inefficient use of the radio channel spectrum. Random assignment of the resources is suitable for bursty type traffic but results in potentially large delay while waiting for the resources to be assigned. It is therefore not suitable for delay-sensitiv

18、e traffic. Demand-based assignment of resources requires that the users explicitly request bandwidth or make reservation for the desirable bandwidth. This scheme may be viewed as bandwidth-on-demand. This scheme is suitable for bursty type traffic and avoids the problems with the previous two scheme

19、s. Demand-based assignment MACs are considered the most appropriate scheme for both packetized voice and data type traffic. The MAC layer typically supports multiple access with different QoS classes. 10.4 Logical Link Control (LLC) The Logical Link Control (LLC) protocol is essentially a procedure

20、between the GPRS mobile station (MS) and the serving GSN (SGSN) in the core network (see GSM 04.64). The primary function of the LLC sub-layer is to take the packet data units coming from the higher layers (in this case the SNDCP sub-layer) and segment them into variable size LLC frames. A 24-bit cy

21、clic redundancy check (CRC) scheme is added to the LLC frame to provide error detection. The functions of the LLC sub-layer may be summarized as follows: - the provision of one or more distinct logical link connections between the MS and the SGSN; - sequence control to maintain the order of the fram

22、es across a logical link connection; 12- detection and recovery from errors on a logical link connection; - notification of unrecoverable errors; - flow control; and - ciphering. The LLC will operate in either an acknowledged or unacknowledged mode. The characteristics of the unacknowledged mode are

23、 as follows, - numbered Unconfirmed Information (UI) frames are transmitted across a link; - the UI frames are not acknowledged at the LLC; - transmission and format errors are detected; - no error recovery mechanism is used; - no flow control procedures are used. This would appear to be the most li

24、kely mode in which voice services would be supported in an integrated voice and data scenario over GPRS. At issue however would be the need to provide an error recovery mechanism for data traffic over the LLC link. The LLC layer is responsible for the correct transfer of link-layer Service Data Unit

25、s (SDUs) across the radio link. This includes functions such as segmentation, reassembly, transmission and retransmission. At the LLC/MAC sub-layers, the treatment of real-time and non-real-time services will be treated differently. The transfer of non-real time data includes the possibility of low-

26、level automatic repeat request (ARQ) offering higher protocol layers reliable data transfer. The overhead when transporting data is largely determined by the header size compared to the user data. For file transfer, the file is most efficiently transferred when the packets are large and the header b

27、ecomes a small percentage of the total packet size. On the other hand, when transporting real-time services over IP, the total packet size should be kept small to minimize the delay. In this case the header is a significant ratio of the total packet size. A comparison of different header sizes are g

28、iven below: Table 1: Comparison of header size Header Size TCP header 24 bytes UDP header 8 bytes IPv4 header 20 bytes IPv6 header 40 bytes LLC 5 9 bytes It should be noted that packets sent over the air interface include headers from layer 4 (TCP/UDP), layer 3 (IP) and layer 2 (LLC/RLC/MAC). By com

29、parison, speech over the GSM circuit-mode radio channel is transmitted in blocks of 260 bits (32.5 bytes) every 20 ms. As a general principle, the framing structure over the air interface is designed to have a large user payload compared with the overhead used to frame that payload. This ensures tha

30、t the air interface is being efficiently utilized. The topic of header size and efficiency is being actively addressed in 3GPP SA2, GERAN and the IETF. 13The user payload as seen at the SNDCP layer is approximately 1500 bytes. Clearly, if the significantly smaller voice packet size is to be carried

31、over the air interface, then the amount of overhead from the various sub-layers will have to be significantly reduced to provide an efficient transmission medium. User Datagram Protocol (UDP) is a connectionless datagram service which means that there is no guarantee that packets will be delivered,

32、or if delivered the packets may be in an order different from the order in which they were sent, or duplicate frames may be delivered. In addition, there is no acknowledgment that data has been delivered. As with TCP, an application transmitting data to another application must first add the UDP hea

33、der to the data, then at the IP layer, further header is added and similarly at the LLC layer. It is clear from the above table that TCP with its significantly larger overhead (compared with UDP) is not a suitable transport layer protocol for IP voice traffic. In summary, the current air interface h

34、as been optimized to reduce the impact of errors over the radio link while providing support for simultaneous multiple users and is unsuitable for real time services. 11 Quality of Service (QoS) QoS may be defined by a set of parameters. This section defines the parameters to be supported in the pos

35、t Phase 1 GPRS network. 11.1 Introduction to QoS The ITU-T Rec. E.800 defines QoS as “the collective effect of service performances which determine the degree of satisfaction of a user of the service.” Rec. E.800 provides a framework for the QoS concept in addition to the relationship between qualit

36、y of service, network performance and a set of performance measures. That framework is used throughout this document to establish a basis for identifying the QoS requirements for Wireless IP Telephony. Quality of Service refers to a number of measurable performance parameters which together provides

37、 a measure of the end-user satisfaction with the service being provided by the network operator. In a packet switching environment, the significant parameters are: - end-to-end delay - delay variation/jitter - throughput - availability - reliability 11.1.1 End-to-end Delay To achieve a satisfactory

38、QoS for real-time voice communication, the delay experienced by the end-user must not only be limited to a maximum value but must also be constant (delay jitter) during the call. The maximum allowable one-way end-to-end delay for acceptable voice communication is 400 ms. ITU-T Recommendation G.114.

39、For good quality real-time voice communication, however, this delay should be limited to a design objective of 150 ms. In a packet (IP) network, this end-to-end delay is made up of several components as follows DTR/TIPHON-05001 version 1.2.5, General Aspects of Quality of Service: - IP terminal dela

40、y 14- packetization/depacketization delay - codec delay - network transmission delay 11.1.2 Delay Jitter With packet switched data networks, a constant end-to-end delay cannot be guaranteed. Each packet sent through the network may be impacted differently by traffic/congestion conditions. Consequent

41、ly, the perceived end-to-end delay will vary over the call duration. This is known as delay jitter. Jitter can be removed from the system through buffering of the packets. The effect of delay jitter will have the most significant impact on the performance of voiceband data modems. The performance me

42、asures that are used to characterize QoS at the air interface are defined at the MAC layer of the protocol stack. The performance measures are dependent on whether the traffic type is real-time (voice and video) or non-real time (data and facsimile traffic). The emphasis in this report is on the sup

43、port for real-time traffic and consequently the voice requirement will be the determining criteria. In a wireless/cellular network it is anticipated that the QoS will fluctuate due in part to the behavior of the radio medium (fading, etc.) and the mobility of the user. It will be very hard to guaran

44、tee a QoS in the same way that is being considered for wireline/fixed networks. One option will be for wireless operators to offer a minimum QoS that will ensure a reasonable level of service guarantee. As the radio interface is the most critical link in the end-to-end connection, special attention

45、will need to be given to determining what QoS can reliably be achieved over the air interface. This can be done by looking at each parameter and how they are impacted by the air interface. 11.1.3 Throughput Throughput is a direct result of the performance of the transmission path used to carry the u

46、ser traffic. In turn, the performance of the path is a function of the errors incurred on the path. In addressing the performance of an IP Telephony network, two types of transmission errors have to be considered: 1. errored packets (due to facility bit errors during transmission; and 2. lost or dis

47、carded packets. The IP layer in the protocol stack will attempt to address errors that occur in the packet header. Errors that occur in the payload of the IP packet, namely the coded speech will have to be addressed at the Transport layer or at the Application layer. This will result in retransmissi

48、on of the corrupted packets and consequently a decrease in throughput. The impact of lost or discarded packets is potentially a more severe performance issue. An IP packet may be lost due to network congestion. In addition, a packet may be discarded at the destination if the delay in the packet arri

49、ving at the destination node is sufficiently large that the node declares the packet lost. The impact of a single lost packet is the loss of one or more coded speech frames, depending on the speech coder in use and the number of frames per packet. In todays GPRS system, the QoS capabilities across the radio interface would be defined within the RLC/MAC layer. In the transmission (and signaling) plane, the RLC/MAC layer is used between the MS and the BSS. Between the BSS and the SGSN, the QoS information is conveyed by the BSSGP protocol. 15In addressing the feasi