1、NTE RNATIONAL TELECOMMUNICATION UNION CCITT THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE GENERAL ASPECTS OF DIGITAL TRANSMISSION SYSTEMS; TERMINAL EQUIPMENTS F G.764 VOICE PACKETIZATION - PACKETIZED VOICE PROTOCOLS Recommendation G.764 I Geneva, 1990 NTE RNATIONAL TELECOMMUNICATI
2、ON UNION G.764 CCITT THE INTERNATIONAL TELEGRAPH AND TELEPHONE CONSULTATIVE COMMITTEE GENERAL ASPECTS OF DIGITAL TRANSMISSION SYSTEMS; TERMINAL EQUIPMENTS VOICE PACKETIZATION - PACKETIZED VOICE PROTOCQLS Recommendation G.764 CCITT RECMN*G.764 90 q862593 0563238 I 6 FOREWORD The CCITT (the Internatio
3、nal Telegraph and Telephone Consultative Committee) is a permanent organ of the International Telecommunication Union (ITU). CCITT is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide
4、basis. The Plenary Assembly of CCITT which meets every four years, establishes the topics for study and approves Recommendations prepared by its Study Groups. The approval of Recommendations by the members of CCITT between Plenary Assemblies is covered by the procedure laid down in CCITT Resolution
5、No. 2 (Melbourne, 1988). Recommendation G.764 was prepared by Study Group XV and was approved under the Resolution NO. 2 procedure on the 14 of December 1990. CCIT NOTE In this Recommendation, the expression “Administration” is used for conciseness to indicate both a telecommunication Administration
6、 and a recognized private operating agency. O IT 1990 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU. CCITT ?CPlN*G.7b4 90 m 4Bb259L
7、 0563239 3 M Recommendation G.764 VOICE PACKETIZATION - PACKETIZED VOICE PROTOCOLES 1 Introduction This Recommendation defines a packet voice protocol for speech packetization in permanent virtual circuit applications. The principal application of the packetized voice protocol (PIT) is at the primar
8、y rate and in fractional primary rate applications. The protocol defines formats and procedures for the transport of voice information and channel associated signalling over a wideband packet network. The Recommendation accommodates additional future types including optional intemetworking capabilit
9、ies with the digital cellular radio networking applications currently under development. The extension of this Recommendation for baseband facsimile traffic is currently under study. This Recommendation does not address performance issues. This Recommendation does not address methods for coding spee
10、ch samples, although particular recommended coding algorithms are specified in the protocol (e.g. the algorithms in Recommendation G.726). In particular, the Recommendation allows dynamic bandwidth allocation and graceful congestion control when the speech samples are coded with embedded algorithms
11、such as those specified in Recommendation G.727. This Recommendation does not address the following issues: 1) services based on the interface; 2) implementation techniques: 3) performance guidelines relative to the use of packetized speech; 4) equipment aspects; 5 trunk signalling, link establishme
12、nt and call establishment procedures for switched virtual circuits; 6) 7) data only issues, combined data/voice issues and frame relay issues; speech packetization in Asynchronous Transfer Mode (ATM) (B-ISDN) systems. 2 Overview This Recommendation contains the specification of a protocol for packet
13、ized speech (FVP). PVP defines formats and procedures for the transport of voice information and channel associated signalling over a packet network. Before packetization, the input speech samples may be coded at the originating endpoint of the transmitting side by one of the coding methods indicate
14、d in this document. The stream of coded speech is transformed into packets with the format specified in this document. The samples are collected over a period of 16 ms and divided into blocks of 128 bits each. Silent intervals may be removed. The blocks are arranged to facilitate block dropping. Per
15、iods of activity and inactivity are respectively called “bursts” and “gaps”. It is not necessary to transmit packets during gaps. Recommendation G.764 1 CCITT RECMN*G=7b4 90 9 4862571 05b3240 T 9 The terminating end at the receiving side reconstructs a continuous stream of speech from the incoming p
16、ackets using the information in the packet header. The build-out delay procedure described in this document compensates for the variable delay that packets may experience within the network. Packets that arrive before their scheduled play-out time are placed in the proper sequence in a packet queue.
17、 Packets that arrive after their scheduled play-out time are discarded. The voice packet header contains information about the level of noise that was measured by the originating endpoint. The terminating endpoint uses this information to play out a matching noise level. An additional feature of PVP
18、 is the ability to drop blocks from a packet as a congestion control mechanism. The n-ih block consists of the n-th bit from each sample collected during the sampling interval. The packet header indicates the number of droppable blocks contained in the packet. Congested nodes may use this informatio
19、n to drop the least significant block from packets to abate the congested state. The signalling associated with each voice connection shall be transported in signalling packets. Signalling packets shall be sent separately on a different logical channel. Transport of the signalling information requir
20、es a set of procedures, similar to those for voice transport, which are described in this document. Note - In a national network, the time stamp (TS) and the build-out procedures of $0 5.1.1, 5.2 and 6.3 may be replaced by a fixed-delay for the first packet. At the originating end, the TS will be se
21、t to zero. In an intermediate node, the TS field will not be updated. However, the build-out procedure will be used always on. network-network and user-network interfaces. 3 Formats 3.1 Physical layer For operations at 1536 kbit/s or 1920 kbit/s, the electrical characteristics and formats of the int
22、erface are those defined in Recommendations G.703, G.704 and 1.431 for the primary rates of 1544 kbit/s and 2048 kbit/s, respectively. The packetized signal consists of one digital stream sent over conventional primary rate facilities. Hybrid situations containing one or more N x 64 kbit/s packet st
23、reams and M conventional 64 kbit/s channels are also considered. 3.1.1 Bit inversion For primary rate applications that require code restrictions that maintain ones density, bit inversion is necessary so that the combined result of bit stuffing and bit inversion is to prevent the all O octet and to
24、satisfy the ones density requirements of restricted DS 1 facilities. 3.1.2 Order of transmission Bit 1 is the least significant bit (LSB) and is transmitted first. Bit 8 is the most significant bit (MSB) and is transmitted last. 3.2 Link layer The link layer of PVP uses a similar approach to Recomme
25、ndation Q.921b.441 with the additions indicated in this Recommendation. Frames that transport voice and frames that transport channel associated signalling are assigned different layer 2 addresses, .e. they are carried on two separate logical links. This, together with the use of a different unnumbe
26、red frame type for each type of traffic, provides an additional measure of security to protect from the misrouting of Signalling information. 3.2.1 Address Beld The address field is two octets in length with the first bit of each defined as an extension bit and bit 2 of octet 1 defined as the comman
27、d/response (C/R) bit. The 13 bits that remain are concatenated to form a single data link connection identifier (DLCI). Address assignment starts with 128 and ends with 8063. Layer 2 addresses are already assigned and the implementation starts from the DLCI-ASSIGNED state. 2 Recommendation G.764 CCI
28、TT RECMN*G.?6V 90 9 4862593 0563ZllL L 3.2.2 Commandlresponse bit The C/R bit (bit 2 of octet 1) is set to O. 3.2.3 Frame types The following two frame types are allowed in PVP. 3.2.3.1 Unnumbered information frames When a layer 3 or management entity requests unacknowledged information transfer, th
29、e unnumbered information (UI) command is used to send information to its peer without affecting data link layer variables. U1 command frames do not carry a sequence number and therefore, the UI frame may be lost without notification. The control field for the UI command frame is a single octet in le
30、ngth. The format and encoding are the same as specified in Recommendation Q.921B.441. The U1 frame is used to transport channel associated signalling. 3.2.3.2 Unnumbered information with header check frame The unnumbered information with header check (UIH) frame has the same applications as the U1 f
31、rame. The difference between the two is that the cyclic redundancy check (CRC) sequence is derived over the frame and packet headers (the first 8 octets excluding flags) rather than over the entire frame. The check sequence fills the last two octets of the UIH frame. The control field of the UIH is
32、a single octet in length and is shown in Figure UG.764. I 8 7 6 5 4 3 2 1 I Bitnumber I 111P1111 FIGURE 1/G.764 Control field of the GIH frame The UIH frame is used to transport voice (see Note). Note - The CRC check of the UIH protects 8 octets which contain the address field (to ensure correct del
33、ivery), the control field (to guarantee the validity of the frame type) and the layer 3 header. It does not protect the voice information because voice traffic is more sensitive to delay due to retransmission than to bit errors and because this allows reduction of the voice information by block drop
34、ping under congestion without recalculating the CRC check. As a consequence, the test for invalid frames in 5 3.2.7 uses the minimum frame length of 10 octets. 3.2.4 Poll bit The poll bit (P) is bit 5 of the UI/UIH frame control field. The P bit shall be set to O. Recommendation G.764 3 CCITT RECMN*
35、G*764 70 = 4862573 0563242 3 3.2.5 Check sequence The check sequence (CS) algorithm is the same as that described in IS0 Recommendation ISO-3309. The CS field shall be a 16-bit sequence. It shall be the ones complement of the sum (modulo 2) of 1) The remainder of (x raised to k power) (x15 + xI4 + x
36、13 + xl2 + XI* + xI0 + x9 + x8 + x7 + fi + x5 + x4 + x3 + x2 + x1 + 1) divided (modulo 2) by the generator polynomial x16 + x12 + x5 + 1, where k is the number of bits in the frame existing between, but not including, the final bit of the opening flag and the first bit of the first octet of the non-
37、droppable octets for the header check sequence (HCS) or the first bit of the check sequence for the frame check sequence (FCS), excluding bits inserted for transparency, and 2) the remainder of the division (modulo 2) by the generator polynomial x16 + x12 + x5 + 1, of the product of xl6 by the conte
38、nt of the frame existing between, but not including, the final bit of the opening flag and the first bit of the first octet of the non-droppable octets for the HCS or the first bit of the CS for the FCS, excluding bits inserted for transparency. As a typical implementation at the transmitter, the in
39、itial content of the register of the device computing the remainder of the division is preset to all ones and is then modified by division by the generator polynomial (as described above) of the address, control and appropriate portion of the information fields; the ones complement of the resulting
40、remainder is transmitted as the 16-bit CS. As a typical implementation at the receiver, the initial content of the register of the device computing the remainder is preset to all ones. The final remainder after multiplication by xl6 and then division (modulo 2) by the generator polynomial x16 + xl2
41、+ x5 + 1 of the serial incoming protected bits and the CS, will be 0001 110100001 11 1 (x15 through fl, respectively) in the absence of transmission errors. 3.2.6 Frame abort Receipt of seven or more contiguous 1 bits shall be interpreted as a frame abort, and the link layer entity shall ignore the
42、frame currently being received. A frame following an abort must begin with an opening flag. 3.2.1 Invalid UIlUIHframes for PVP For the purposes of PVP, an invalid UI/IH frame is a frame which: 1) 2) 3) is not properly bounded by two flags; or has fewer than 10 octets between flags: or has greater th
43、an 490 octets between flags; or 4) does not consist of an integral number of octets prior to zero bit insertion or following zero bit extractions; or 5) contains a FCS error. Invalid frames shall be discarded without notification to the sender. No action is taken as the result of that frame. 3.3 Pac
44、ket layer The packet layer procedures apply to the information transfer phase only. Call control procedures are outside thc scope of this Recommendation. 3.3.1 Voicepacket format The format of voice packets is shown in Figure 2/G.764 within the UIH voice frame. Note - The reserved bits are set to O
45、at the originating endpoint. They shall be ignored at the terminating endpoint. They shall not be used fortesting or maintenance purposes in anticipation of possible future uses. 4 Recommendation G.764 CCITT RECMN*G=7b4 90 4862593 0563243 5 87654321 Address (upper subfield) O0 Address (lower subfiel
46、d) 1 UIH control field 111P1111 Protocol discrimator 01000100 I Block dropping indicator I Time stamp JMIRIRI Coding type Noise I I Sequence number I Non-droppable blocks I Optionally droppable blocks I Check sequence 2 octets Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 Octet 7 Octet 8 M More bi
47、t P Poll bit = O (see 9 3.2.4) R Reserved for future use FIGURE 2/G.764 UIH voice frame format 3.3.1.1 Protocol discriminator The protocol discriminator (PD) field is the first octet of the packet header (octet 4, the frame in Figure 2/G.764). Its value for the PVP is given in Figure 3/G.764. 8 7 6
48、5 4 3 2 1 Bit number 01000100 FIGURE 3/G.764 Protocol discrimator for the PVP Recommendation G.764 5 CCITT RECMN*G-764 70 W 4862573 05b3244 7 3.3.1.2 Block dropping indicator The block dropping indicator (BDI) tracks the status of block dropping within the voice packet. A block consists of bits of t
49、he same significance collected from all speech samples that are packetized. The size of the block is 128 bits, which, for a sampling rate of 8 kHz, corresponds to a packetization interval of 16 ms. Blocks are arranged in decreasing order of significance. The format of the BDI is shown in Figure 4/G.764. Bit number I I R Reserved for future use FIGURE 4/G.764 Block dropping indicator format The combination C1 and C2 form the C-subfield that indicates the number of blocks that are still droppable at any intermediate node in the network, as shown in Table UG.764: TABLE UG.764 C-sub
