Itu

ITU - Telecommunication Standardization Sector Temporary Document 21 (GEN)

STUDY GROUP 16

Geneva, 5 – 15 February 2002

Question(s): 2, 3, 11, 14/16

SOURCE*: Rapporteur *

TITLE: Draft Recommendation G.799.1 V65.0

__________________

This is the full text of the Recommendation that appears in GEN 7 : Liaison statement: Request for comments on G.799.1 – support of modem over IP

ABSTRACT:

This contribution constitutes a revision of draft Recommendation G.799.1, Functionality and Interface Specifications for GSTN Transport Network Equipment for Interconnecting GSTN and IP Networks, incorporating the changes that were agreed to at meeting.

1. Introduction:

Question 7 of Study Group 15 has been created to produce a new Recommendation on the functionality and interface specifications for GSTN transport network equipment for interconnecting GSTN and IP networks.

Currently there is no globally recognised equipment standard defining the functionality or interface characteristics of Network-Network Interfaces designed for connection GSTN and IP based networks. Not only does this jeopardize the voice quality that results from such interconnection, but also it unnecessarily complicates the network operator’s task of selecting and configuring such equipment.

This document constitutes a draft Recommendation that addresses the various functionality, interface and interworking aspects of this equipment.

* Full text only in electronic version* Contact: Jerry Skene

Tellabs, OY (Finland)Tel: +1 703 724-7302Fax: +1 703 724-7202E-mail: [email protected]

Attention: This is not a publication made available to the public, but an internal ITU-T Document intended only for use by the Member States of the ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU related work. It shall not be made available to, and used by, any other persons or entities without the prior written consent of the ITU-T.

ITU-T\SG_DOC\SG16\FEB02\GEN\GEN-021.DOC

2

Recommendation G.799.1

Summary

Voice and voice-band traffic in international networks has traditionally been transported by circuit switched systems and equipment. With the advent of the networks optimized for the transport of Internet Protocol (IP), and as a result of its considerable growth and pervasive nature, more and more voice traffic is expected to be carried over IP networks.

Given that voice and voice-band services remain a significant part of telecommunications, there is a need to ensure a high quality of service for voice carried in part or wholly via IP. This Recommendation defines interfaces and functionality for equipment that interconnect GSTN and networks optimized for the transport of IP, such that they will provide the degree of voice quality and interoperability required.

Introduction and Background

Keywords

Gateway, IP gateway, TDM-IP gateway, signalling interface, bearer interface, voice gateway, Voice Over IP, internet protocol, internet gateway, end-to-end transmission performance, fax over IP, media gateway, media gateway controller, TDM, VoIP, voice quality, quality of service, echo canceller, speech coding, TIGIN.

Scope

This Recommendation covers the requirements of equipment that interconnects GSTN networks and networks optimized for the transport of IP. Such equipment is referred to in this document as a TIGIN gateway. The Recommendation describes functionality, transport interfaces, coding protocols, signalling interfaces, and OA&M interfaces of these devices. Support is provided for calls from IP to GSTN, GSTN to IP, IP to IP and GSTN to GSTN. While such TIGIN gateways may support multimedia traffic and Remote Access Server (RAS) functionality, this Recommendation covers only voice, and voice-band data, facsimile, narrowband digital data, address and signalling tones. traffic requirements. Support of other media such as digital data and video are left for further study. In this sense, a TIGIN gateway is a subset of a Media Gateway.

This Recommendation does not define any new protocols or network architectures, but rather refers to existing protocols and architectures. It also does not specify a level of performance, as this will be covered by other Recommendations referenced by this document. Operation and management procedures are outside the scope of this Recommendation.

TIGIN Gateways are assumed to support bulk interconnection between GSTN and IP networks, and are not intended to connect directly to Simple Endpoint Type devices. They are considered to be a trunking and not an access gateway. Support of ATM on the GSTN interface is not specifically defined in this release.

/tt/file_convert/563db8e7550346aa9a980ce2/document.doc 18.04.23

3

FUNCTIONALITY AND INTERFACE SPECIFICATIONS FOR GSTN TRANSPORT NETWORK EQUIPMENT FOR INTERCONNECTING GSTN AND IP NETWORKS

(Geneva, 2001)

1 References

1.1 Normative References

The following ITU-T Recommendations, and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; all users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published.

– ITU-T Recommendation E.370 (10/00) Service principles when public circuit switched international telecommunication networks interwork with IP-based networks

– ITU-T Recommendation G.109 (09/99) Definition of categories of speech transmission quality

– ITU-T Recommendation G.168 (04/00), Digital network echo cancellers

– ITU-T Recommendation G.177 (09/99) - Transmission planning for voiceband services over hybrid Internet/PSTN connections

– ITU-T Recommendation G.701 (03/93) - Vocabulary of Digital Transmission and Multiplexing and Pulse Code Modulation (PCM) Term

– ITU-T Recommendation G.703 (10/98) Physical characteristics of hierarchical digital interfaces

– ITU-T Recommendation G.704 (10/98) Synchronous frame structures used at 1544, 6312, 2048, 8488 and 44,736 kbits/s hierarchical levels

– ITU-T Recommendation G.707 (10/00), Network Node Interface for the Synchronous Digital Hierarchy (SDH)

– ITU-T Recommendation G.711 (1988) - Pulse code modulation (PCM) of voice frequencies

– ITU-T Recommendation G.711 Appendix I, (09/1999), A high quality low-complexity algorithm for packet loss concealment with G.711

– ITU-T Recommendation G.711 Appendix II, (02/2000), A comfort noise payload definition for ITU-T G.711 use in packet-based multimedia communication systems

– ITU-T Recommendation G.723.1 (03/96), Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s

– ITU-T Recommendation G.723.1 Annex A, (11/1996), A silence compression scheme for G.729 optimized for terminals conforming to Recommendation V.70

– ITU-T Recommendation G.726 (12/90) - 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)


4

– ITU-T Recommendation G.729 (03/96) - Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction

– ITU-T Recommendation G.729 Annex B - (11/96), Silence compression scheme

– ITU-T Recommendation G.784 (06/99) - Synchronous Digital Hierarchy (SDH) management

– ITU-T Recommendation G.813, (08/96) - Timing characteristics of SDH equipment slave clocks

– ITU-T Recommendation G.957 (06/99) - Optical interfaces for equipments and systems relating to the synchronous digital hierarchy

– ITU-T Recommendation G.965, (03/95) - V-INTERFACES AT THE DIGITAL LOCAL EXCHANGE (LE) – V5.2 INTERFACE (BASED ON 2048 kbit/s) FOR THE SUPPORT OF ACCESS NETWORK (AN)

– ITU-T Recommendation H.225.0 (11/00) - Call signalling protocols and media stream packetization for packet-based multimedia communication systems

– ITU-T Recommendation H.323 (02/98) - Packet based multimedia communication system

– ITU-T Recommendation H.245 (02/00) - Control protocol for multimedia communication

– ITU-T Recommendation H.248 (10/00) - Gateway Control Protocol

– CCITT Recommendation I.233.1 (1991), Frame mode bearer services: ISDN frame relaying bearer service.

– ITU-T Recommendation I.363.1 (08/96) - B-ISDN ATM Adaptation Layer specification: Type 1 AAL

– ITU-T Recommendation I.363.2 (11/00) - B-ISDN ATM Adaptation Layer (AAL) type 2 specification

– ITU-T Recommendation I.363.5 (08/96) - B-ISDN ATM Adaptation Layer specification: Type 5 AAL

– ITU-T Recommendation M.3100 (07/95) Generic Network Information Model

– ITU-T Recommendation Q.2 (11/88) - Signal receivers for automatic and semi-automatic working, used for manual working

– ITU-T Recommendation Q.55 (12/99) – Signalling Between Signal Processing Network Equipment (SPNE) and International Switching Centres (ISC)

– ITU-T Recommendation Q.109 (11/88) - Transmission of the answer signal in international exchanges

– ITU-T Recommendation Q.115 (12/99) - Logic for the control of echo control devices

– ITU-T Recommendation Q.400 (11/88) - Forward line signals

– Recommendation T.38 (06/98) - Procedures for real-time Group 3 facsimile communication over IP networks

– ITU-T Recommendation V.18 (11/00) - Operational and interworking requirements for DCES operating in the text telephone mode

– IEEE Standard 802-1990 - IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture.


5

– IETF RFC 1332 (05/92), The PPP Internet Protocol Control Protocol, (Proposed Standard) IETF RFC 1661 (07/94) The Point-to-Point Protocol (PPP) (Standard)

– IETF RFC 1812 (06/95), Requirements for IP Version 4 Routers, June 1995 (Proposed Standard)

– IETF RFC 1889 (01/96), RTP: A Transport Protocol for Real-Time Applications (Proposed Standard)

– IETF RFC 2131 (03/97), Dynamic Host Configuration Protocol, (Draft Standard)

– IETF RFC 2225 (04/98), Classical IP and ARP over ATM, (Proposed Standard)

– IETF RFC 2427 (09/88) Multiprotocol Interconnect over Frame Relay (Standard)

– IETF RFC 2579 (04/99) Textual Conventions for SMIv2 (Standard)

– IETF RFC 2615 (06/99) PPP over SONET/SDH (Proposed Standard)

– IETF RFC 2684 (09/99), Multiprotocol Encapsulation over ATM Adaption Layer 5, (Proposed Standard)

– IETF RFC 2719 (10/99), Framework Architecture for Signalling Transport, (Informational)

– IETF RFC 2833 (05/00), RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, (Proposed Standard)

– ISO/IEC TR 8802-1:1997 Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Specific requirements -- Part 1: Overview of Local Area Network Standards

– ISO/IEC 8802-3:2000 Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Specific requirements -- Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications

1.2 Informative References

– ITU-T Recommendation G.806 (10/00) – Characteristics of transport equipment – Description methodology and generic functionality

– ITU-T Recommendation Y.1310 (02/00), Transport of IP Over ATM In Public Networks

– ITU-T Recommendation Q.931 (05/98) – ISDN User-Network Interface Layer 3 Specification for Basic Call Control

– ITU-T Recommendation V.32 (03/93), A family of 2-wire, duplex modems operating at data signalling rates of up to 9600 bit/s for use on the general switched telephone network and on leased telephone-type circuits

– ITU-T Recommendation V.34 (02/98), A modem operating at data signalling rates of up to 33 600 bit/s for use on the general switched telephone network and on leased point-to-point 2-wire telephone-type circuits

– IETF RFC 2472 - IP Version 6 over PPP( proposed standard)


6

1.3 Terms and Definitions

For terms and definitions not appearing in this section, see Recommendation G.701 (03/93), Vocabulary of Digital Transmission and Multiplexing and Pulse Code Modulation (PCM) Terms.

general switched telephone network (GSTN):

This network includes ATM, PSTN, ISDN, wireless networks and private networks.

media gateway (MG):

The media gateway converts media provided in one type of network to the format required in

another type of network. For example, a MG could terminate bearer channels from a switched

circuit network (e.g., DS0s) and media streams from a packet network (e.g., RTP streams in an IP

network). This gateway may be capable of processing audio, video and T.120 alone or in any

combination, and will be capable of full duplex media translations. The MG may also play

audio/video messages and performs other IVR functions, or may perform media conferencing. For the purpose of this Recommendation, the term media gateway refers to a voice gateway.

media gateway controller (MGC):

Controls the parts of the call state that pertain to connection control for media channels in a media gateway

simple endpoint type devices (SET):

See H.323 Annex F.

TIGIN Gateway

A voice gateway complying with this Recommendation

voice gateway (VG):

A voice gateway is a subset of a media gateway that deals with voice and voiceband traffic only, and not data or video traffic.

1.4 Abbreviations

This Recommendation uses the following abbreviations.

ATM Asynchronous Transfer Mode

DHCP Dynamic Host Configuration Protocol

DS0 Digital Signal, level 0

DTMF Dual Tone Multi-Frequency

DTX Discontinuous Transmission

GSTN General Switched Telephone Network


7

IETF Internet Engineering Task Force

IP Internet Protocol

ITU International Telecommunication Union

MG Media Gateway

MGC Media Gateway Controller

MGCP Media Gateway Control Protocol

NMS Network Management System

PCC Per Call Control

PCM Pulse Code Modulation

PPP Point to Point Protocol

PSTN Public Switched Telephone Network

RTCP Real Time Control Protocol

RTP Real Time Protocol

SCN Switched Circuit Network

SDH Synchronous Data Hierarchy

SET Simple Endpoint Type

SNMP Simple Network Management Protocol

TCP Transmission Control Protocol

TDM Time Division Multiplex(ing)

TFO Tandem Free Operation

TIGIN Transport Network Equipment for Interconnecting GSTN and IP Networks

TMN Telecommunication Management Network

UDP User Datagram Protocol

VBD Voiceband Data

VoIP Voice over IP

2 General Description of GSTN Transport Network Equipment for Interconnecting GSTN and IP Networks (TIGIN)

In practice, a TIGIN gateway may be composed of multiple pieces of equipment, each with specialized functions, such as signalling interfaces, voice compression/decompression, packetization, etc. Figure 1 illustrates some of the functions performed in a gateway. This Recommendation does not specify how these functions are to be performed, nor does it specify the specific interconnections, which may be implemented between functions. It is recognized that the functions of a media gateway controller (MGC) may be combined with those of a TIGIN gateway in the same physical device. In this situation, certain interfaces described in this Recommendation may not be present. This Recommendation does not cover the requirements of such a controller.


8

Figure 1/G.799.1: Illustration of functions performed by a TIGIN gateway.

Each of the elements included in the above block diagram is described in detail in the following sections.

3 Interfaces

The overall relationship between the TIGIN gateway and other devices and protocols in the network is illustrated in figure 2.


9

Figure 2/G.799.1 Relationship between TIGIN gateway and other IP-related standards

3.1 IP Bearer Interfaces

The IP interface block in the block diagram in Figure 1 provides the transmission facility interface for the network element to the IP network. It terminates all the lower layers and much or all of the upper layers of the incoming signal from the IP network. It also performs alarm detection and performance monitoring of the interface layers. It then sends the data to the Packetizer block for further processing. It performs the inverse function in the transmitting direction towards the IP network.

The layers of the IP bearer interface should conform to at least one of the interface types from the following section. Voice and voiceband data and higher layers on this interface should conform to that specified in H.323. Higher layer protocols may include any of the following: TRP, UDP, and RTCP. Facsimile traffic may use ITU-T Recommendation T.38.

Figure 3.1 shows layers of TIGIN IP bearer interface model.

Application Transparent Voice

Tones FAX TIGIN Control

Management Signalling System No. 7 Transport

Upper Layers

RTP T.38 H.248/MGCP SNMP/TMN M2UA*


10

Transport Layer

UDP (User Datagram Protocol) SCTP

IP Layer IP (Internet Protocol)

Lower Layers

Physical and Data Link

Figure 3/G.799.1- IP Bearer Interface Protocol Layers

* Editor’s Note: This depends upon the results of a liaison sent to SG11 and IETF.

Figure 3 shows only a basic stack. Additional function for Quality of Service (QoS), security, header compression, etc. may be added.

3.1.1 Lower Layers

This Recommendation does not restrict using of any lower layer protocol intended for IP packet transmission and approved by an internationally recognized standards body.

Lower layer interface performs link protection, alarm detection and performance monitoring of the interface layers as define in appropriate standards.

3.1.2 IP Layer

IP protocol should conform to IETF RFC 791, RFC 950, RFC 919 and RFC 920.

Support of MPLS is for further study.

Support of IP V6 is for further study.

IP network topology, IP packet distribution and routing protocols are not the subject of this Recommendation.

3.1.3 Transport Layer

UDP protocol is used as transport layer protocol and it should conform to IETF RFC 768.

SCTP protocol is used for transport PSTN signalling messages over IP networks and it should conform to IETF RFC 2960.

TCP protocol (RFC 793) may be optionally used for non time critical applications.

3.1.4 Upper Layers

RTP protocol is used for transparent signal transmission and for voice and tones transmission as IETF RFC 1889 describes. IETF RFC 1889 also defines RTCP (Real Time Control Protocol) as a companion control protocol for RTP.

A TIGIN gateway should support both transparent G.711 and T.38 fax protocol for fax transmission.

Other types of application interfaces are described later in this section.


11

3.1.5 Layer 3

Layer 3 protocols may include any of the following:

DHCP - IETF RFC 2131

IP V4 Router - IETF RFC 1812

Support of IP V6 (IETF RFC 2472 - IP Version 6 over PPP ) is for further study.

3.1.6 Layer 2


PPP (x.ip)

Frame Relay – I.233-

ATM I.363.1, I.363.2, I.363.5

IP over PPP, as per IETF - RFC 1661

IP over Frame Relay, as per IETF - RFC 2427

IP over ATMIP over PPP over SDH, as per IETF - RFC 2615

3.1.7 Layer 1


G.704, G.707, G.703, G.957, ISO/IEC 8802-3, ISO/IEC 8802-1

3.2 GSTN (TDM) Bearer Interfaces

The TDM interface block in the block diagram in Figure 1 provides the transmission facility interface for the network element to the GSTN network. The physical layer of the TDM bearer interface should consist of at least one of the interface types in the table below. Voice and voiceband coding on this interface should conform to G. 711. Mechanisms for tandem coder avoidance are for further study.

Layer 1 G.704, G.707, G.703, G.806, G.957

3.3 Call Control Interfaces

3.3.1 Per Call Control (PCC)

PCC describes the interface between the TIGIN and the MGC that provides for real-time per call control of TIGIN. The MGC is the control element that interworks between the signalling network and TIGIN, providing the TIGIN with the real-time per-call control signals.

The PCC protocol defines the messaging between the MGC and TIGIN and allows for the following capabilities such as:

Establish, modify, and release connections within the TIGIN, including originating and terminating addresses (e.g. TDM-TDM, TDM-IP)

Query the status of connections or resources within the TIGIN

Notification of call-related alarms or failures


12

Continuity Check

Transfer of certain GSTN Signalling information for MF and CAS based protocols carried on the TDM link

PCC allows the MGC to specify the internal TIGIN resources required in the connection path (Echo control, DTMF detection, Modem/Fax detection, etc.). It also allows for the setting of per call features and parameters required based on call type and interoperability needs. . These parameters may include some or all of the followingsuch as:

Real time call processing event notification, including the control of echo cancellers

Silence Suppression activation

Comfort Noise Generation

Jitter Buffer size

Selection of and/or negotiation of codec (e.g. G.711, G.723.1, G.729). Selection of different codecs on the GSTN and IP interfaces implies performing a transcoding function (e.g., G.711 to G.729). It is recommended that ITU-T Recommendation H.245 be used for codec negotiation.

Packet size selection

Mechanisms for supporting the above features are for further study. Selection of these mechanisms will affect voice quality. See sections 4.1, 4.2 & 4.3 for more information on this topic.

Upon completion of a call, as specified in H.248 PCC protocols, TIGIN should be capable of supplying, upon request, statistics related to the call, for example:

Number of packets sent

Number of octets sent

Number of packets received

Number of octets received

Average Inter-arrival jitter

Average transmit delay

Average receive delay

Packet loss

Mechanisms for supporting the above features are for further study. Selection of these mechanisms will affect voice quality. See sections 4.1, 4.2 & 4.3 for more information on this topic.


13

The upper layer protocol used should conform to one of the following:

H.248

MGCP (RFC 2705) – optional

Note: If H.248 is not used, then certain gateway capability such as NLP control of integrated echo cancellers may not be available.

. Lower layer protocols should conform to one of those listed in sections 3.1.1, 3.1.2, or 3.1.3. Use of the MGCP protocol on this interface is for further study.

Examples of protocols that may be used on this interface include:

IEEE Std 802-1990, IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture

1 Gbps Ethernet

TCP or UDP/IP

Any link layer protocol approved by an internationally recognized standards body

The PCC interface may share the same circuit as the IP bearer interface.

3.3.2 Signalling over IP

A framework architecture for signalling transport over IP networks may be found in IETF RFC-2719.

3.3.2.1 Out-of-band signalling

As described in H.248, TIGIN interfaces to the Signalling Gateway through the Media Gateway Controller (which is referred in H.248 as the Call Agent). As a consequence, the Media Gateway Controller implements the "signalling" layers of the H.323 standard, and presents itself as an "H.323 Gatekeeper" or as one or more "H.323 Endpoints" to the H.323 systems.

Signalling exchanges with the Media Gateway Controller are done through H.225/RAS and H.225/Q.931.

Possible negotiation of logical channels and transmission parameters with the Media Gateway Controller are done through H.245.

3.3.2.2 In-band signalling

There are some applications that require support for in-band signalling:

Internet telephony gateway that detects the DTMF signals on the incoming circuits and sends the appropriate digits as RTP payload (see IETF RFC-2833)

Internet end system such as an "Internet phone" can emulate DTMF functionality without generating precise tone pairs and without imposing the burden of tone recognition on the receiver

When the coder used destroys the in-band signalling information (like G.723.1)

In such cases, the support for in-band signalling will be done in accordance with IETF RFC-2833.


14

3.3.2.3 Signalling Backhaul

The Signalling Backhaul interface exists between the TIGIN Gateway and the Media Gateway Controller. Its purpose is to transfer GSTN signalling information that arrives at the TDM interfaces of the TIGIN Gateway to the MGC and vice versa.

In some cases the Signalling Backhaul interface exists between the TIGIN Gateway and the Signalling Gateway. In such cases the requirements on the TIGIN Gateway are no different from the general case (termination on MGC).

Signalling Backhaul exists for two families of GSTN signalling, namely Common Channel Signalling and MF/CAS Based Signalling. Each case is handled in a different manner.

3.3.2.3.1 Signalling Backhaul for Signalling System No. 7

For backhaul of common channel signalling a common reliable transport protocol, SCTP (RFC 2960), may be used.

For encapsulating the higher layers of GSTN signalling protocols, MTP3 (see Q.704) the MTP2 User Adaptation Layer (M2UA – see draft-ietf-sigtran-m2ua-10.txt) may be used.

3.3.2.3.2 Signalling Backhaul for MF and CAS-based Signalling

For the “backhaul” of the call control information associated with MF and CAS based GSTN signalling protocols (such as R1, R2, robbed bit signalling) then H.248 or MGCP packages defined for the Per Call Control protocols defined in 3.3.1 may be used.

Note that the information carried in the PCC packages is a translation of the GSTN signalling and not a copy of the signalling, as would be the case for Signalling System No. 7 backhaul.

3.4 TDM Signalling Interface

TDM Bearer signalling is accomplished by means of signalling on the TDM bearer interface.

TDM Bearer Signalling may be accomplished by means of signalling on the TDM bearer interface. TDM bearer signalling interfaces supported by this recommendation should conform to national standards.

The following paragraphs describe the responsibility of the TIGIN Gateway when it supports TDM Bearer Signalling interfaces.

3.4.1 SS7 Signalling Links

When SS7 signalling links (e.g. associated links carried in E1 TS16) are connected to the TIGIN Gateway then the Gateway should terminate the MTP Link layer (MTP2) in accordance with Q.703 and should transport the higher layers (MTP3 and above) between itself and the MGC/SG as described in 3.3.2.3.1.

If non-associated links are deployed in the GSTN then these will not be handled by the TIGIN Gateway as they will be delivered directly to the SG or MGC.


15

3.4.2 CAS & MF Based Signalling

When CAS and MF based signalling is connected to the TIGIN Gateway (such as R1, R2, robbed bit signalling) then the Gateway should detect/generate the signalling and provide interworking between the signalling and H.248/MGCP as described in 3.3.2.3.2.

TDM signalling interfaces supported by this Recommendation should conform to national standards and are for future study.

If SS7 A – link is used, then signalling on the TDM bearer interface is not used.

Support of the following and other signalling types is for further study:

SS7 Signalling

Q.931

R1 – Q.2

R2 – Q.400

V 5.2 (G.965)

Channel Associated as per G.704

3.5 Management Interface

Both TMN and SNMP management interfaces are for further study.

4 TIGIN Functionality

4.1 Signal Processing Functions

The network element supports voice-related features as described in this section. Some or all of the voice feature functions listed in this section may be utilized during a call. The PCC message specifies which functions should be used on a call.

As an example, silence suppression and comfort noise generation may be requested on a call that uses G.711 coding. The network element in that case would take the GSTN data, interpret it as G.711 coding and generate packets to the IP network using G.711 coding only if it detects speech activity. In the reverse direction, it would receive packets from the IP network, interpret them as G.711 encoded PCM, convert the packets into a synchronous (TDM) stream and send it to the GSTN network. During the time packets are not received it would generate comfort noise G.711 PCM values and send it to the GSTN network.

In addition, other signal processing features supported by the network element could include the following:

Continuity Check tone generation and detection

Continuity Check loop-back

Signal processing functions may affect voice quality. See sections 3.3.1 & 4.3 for more information on this topic.


16

4.1.1 Echo Control

In compliance with ITU-T Recommendation G.177, Transmission Planning for voiceband services over hybrid internet/PSTN connections, a voice-over-IP connection traversing a hybrid is required to include a G.168 compliant echo canceller. Since the echo canceller needs to have a constant delay for its echo path, it should be placed so that the echo path is on the TDM side of the interface that includes the hybrid. Issues that need to be addressed are:

Issues related to modem and other voice-band data signals

Tail Capacity

Network Operators and Service Providers should ensure that echo cancellation is applied in the most appropriate location for the specific configuration. The echo canceller should be associated with the TIGIN gateway in one of three possible configurations, as outlined in the following sections.

It should be reinforced that all voice connections involving GSTN to IP interworking involving a hybrid require echo cancellation and the Network Operator or Service Provided choosing to utilize either configuration B or C below should ensure that an echo canceller is provisioned on the TDM bearer side of the hybrid Internet/ GSTN connection.

4.1.1.1 TIGIN Internal Echo Control – Configuration A

In this configuration the echo canceller is integrated into the TIGIN gateway itself as shown in Figure 3. With this configuration, H.248 messages conveying are generated by the Q.115 echo control logic in the MGC and are sent to the TIGIN gateway. The TIGIN gateway then directly controls the internal echo canceller function in accordance with the messages received. For this configuration, the echo canceller function within the TIGIN gateway is required and the Q.55/Q.52 process is optional but not used.

Figure 3/G.799.1: Echo canceller integrated into TIGIN gateway – Configuration A


17

4.1.1.2 TIGIN External Echo Control With Q.55/Q.52 Control – Configuration B

In this configuration the echo canceller is directly associated with and controlled by the TIGIN gateway, as shown in Figure 4 below. With this configuration, H.248 messages conveying are generated by the Q.115 echo control logic information in the MGC and are sent to the TIGIN gateway. The TIGIN gateway then converts the messages into appropriate protocol data units and sends them to the associated external echo canceller. The conversion processes are described in sub-section 4.1.1.2.1. For this configuration, the echo canceller function within the TIGIN gateway is optional but not used, and the Q.55 process is mandatory.

Figure 4/G.799.1: TIGIN External Echo Control With Q.55 Control – Configuration B

4.1.1.2.1 Echo Canceller Control Procedures

When the echo cancellation function is not integrated into the TIGIN gateway, but is located on a TDM trunk of the gateway and is controlled by the TIGIN gateway, the following procedures should be used. These procedures define the mapping between H.248 messages received by the TIGIN gateway from the media gateway controller and Q.55 protocol data units transmitted to the associated external echo canceller.

Echo canceller enable procedure:When the H.248 package responsible for controlling echo cancellers is received with the value set to “on” for a specific TDM DS0 channel, the Q.55 protocol data unit “enable echo cancellation for channel n”, as defined in Annex H/Q.55, where ‘n’ is the DS0 channel specified by the H.248 message, is transmitted on the Q.55 echo control interface of the TIGIN gateway.


18

Echo canceller disable procedure:When the H.248 package responsible for controlling echo cancellers is received with the value set to “off” for a specific TDM DS0 channel, the Q.55 protocol data unit “disable echo cancellation for channel n”, as defined in Annex H/Q.55, where ‘n’ is the DS0 channel specified by the H.248 message, is transmitted on the Q.55 echo control interface of the TIGIN gateway.

4.1.1.3 GSTN Switch Associated Echo Control – Configuration C

In this configuration the echo canceller is not directly associated with or controlled by the TIGIN gateway. Instead, the echo canceller is associated with and may be controlled by a switch in the GSTN as shown in Figure 5 below.

If the GSTN switch controls the echo canceller, it may either be controlled via a Q.55 interface, or, via some other control mechanism. If the GSTN switch controls the associated echo canceller via Q.55, echo control messages are generated as a result ofby the Q.115 echo control logic information in the GSTN switch and are sent to the GSTN switch-associated echo canceller. For this configuration, while the echo canceller function and/or Q.55 process within the TIGIN gateway may exist, they are not used.

It should be noted that the Q.115 echo control logic in the MGC will request the disablinge of a canceller associated with the TIGIN gateway, if any is present, as in this particular case one has already been provisioned in the GSTN.

Figure 5/G.799.1: Non-TIGIN Associated Echo Control – Configuration C


19

4.1.1.4 Media Gateway Controller Direct Control - Configuration D

It is possible for the MGC to directly control the echo canceller, without going through the media gateway, as shown in figure 6. In this scenario, there is a direct connection vie an H.248 connection from the MGC to the echo canceller.

Echo control messages are generated by the Q.115 echo control logic in the MGC and are sent to the echo canceller over an H.248 connection. As in the above configuration, while the echo canceller function and/or Q.55 process within the TIGIN gateway may exist, they are not used. It should be noted that the Q.115 echo control logic in the MGC will disable a canceller integrated into the TIGIN gateway, if any is present, as in this particular case one has already been provisioned in the GSTN.

Figure 6/G.799.1: Direct Control of Echo Canceller by MGC– Configuration D

4.1.2 Voice Coding

Voice codec used (e.g. G.711, G.723.1, G.729)

As a minimum, a TIGIN gateway should include a G.711 codec (for both A and mu-laws). In order to allow tandem coder avoidance for calls from and to cellular networks, the TIGIN gateway should optionally include voice codecs commonly used in cellular networks. The included codecs should be those used in the specific cellular network to which the gateway is directly attached.

Delay caused by voice coding should be kept to a minimum (see G.114 Annex A for calculation of delay figures).

Voice coding (e.g. G.729 through G.711 to G.726 )


20

There should be a method of ensuring synchronous reset capability of low bit rate voice coders. For codecs of this type, using an external synchronous reset will be beneficial to voice quality, particularly at the transient from silence to active speech when the codec is used in the DTX condition. If generic SID comfort noise insertion is used with a low bit rate coder, synchronous reset between encoder and decoder should be employed.

Delay caused by voice coding should be kept to a minimum.

4.1.3 Digital Speech Interpolation

Silence suppression and comfort noise generation can be either internal or external to the codec.

Internal Silence Suppression and Comfort Noise Generation

Silence Suppression

Silence suppression should be supported according to the speech codecing used, e.g. G.711 Appendix II, G.729 Annex B for G.729, or G.723.1 Annex A for G.723.

Comfort Noise Generation

Comfort noise generation should be supported according to the speech codec coding used, e.g. G.711 Appendix II for G.711, G.729 Annex B for G.729, or G723.1 Annex A for G.723.1.

External Silence Suppression and Comfort Noise Generation

Voice coding (e.g. G.729 through G.711 to G.726 )

There should be a method of ensuring synchronous reset capability between encoder and decoder of G.726, G.727, G.728 and G.729 when external comfort noise generation is used with these codecs. In these cases an external synchronous reset will be beneficial to voice quality, particularly at the transient from silence to active speech when the codec is used in the DTX condition. If generic SID comfort noise insertion is used with a low bit rate coder, synchronous reset between encoder and decoder should be employed.

4.1.4 Tones and Announcements

Tone generation

Tone generation is for further study.

Tone detection

Tone detection is for further study.

Announcements (optional)

Support of announcements is for further study.


21

4.1.5 Facsimile and data handling

Fax modem bypass

Fax modem bypass is for further study.

Fax modem relay

Fax modem relay is for further study.

Data modem bypass

Data modem bypass is for further study.

Data modem relay

Data modem relay is for further study.

4.1.6 Speech ReconstructionVoice coders in a TIGIN gateway should follow established rules for speech reconstruction under conditions of lost packets. Packet loss concealment techniques should be provided for all codecs supported by the TIGIN Gateway, e.g., G.711 Appendix II, G.729, G.723.1and G.728 Annex I. It should be noted that G.729 and G.723.1 have packet loss concealment capabilities embedded into their respective decoders.

4.1.7 Voice encryption

Methods of supporting voice encryption are for further study.

4.1.8 Distributed Speech Recognition and Distributed Speaker Verification

Methods of supporting Distributed Speech Recognition and Distributed Speaker Verification are for further study.

4.1.9 GSTN signal type classification

The use of speech compression algorithms may impair non-voice signals (e.g. Voiceband Data signals (VBD) or DTMF). A classification process should be provided to distinguish between the following types of signals existing in GSTN:

Voice signals.

Voiceband Data signals (e.g.: Facsimile machines, Dial-Up modems etc.)

The classification process comprises of a set of detectors and a State-Machine.

4.1.10 Detectors

The primary method of new call detection is via messages received from the per-call-control signalling link to the MGC, via H.248 or other signalling over IP (for further study). If new call indication is not available through this link, then the TIGIN gateway will determine new call status through signal processing of the speech channel.

The media gateway pre-processing function should use the following detectors:

New Call Indicator

Speech Detector

Voiceband (VBD) Detectors (e.g.: V.34 detector, V.32 detector, Facsimile detector, etc.).


22

End of VBD Detectors.

4.1.11 State Machine

The state machine illustrated in the figure 7 defines the two basic states and the transition conditions.

Figure 7/G.799.1 - Signal Classification process State Machine diagram

4.1.11.1 Voice state

Voice State is the default state of the Signal Classification process State Machine.

4.1.11.2 VBD state

The transition from Voice state to VBD state is performed when the VBD Detectors classify an input signal as VBD.

When End of VBD Detectors find the end of the VBD transmission, or a speech signal is detected by the Speech Detector or there is a New-Call indication, a transition to the Voice State is performed.

4.1.12 Input pre-processing

The input signal pre-processing function examines the activity/type and state transitions originating from the intermediate trunk classification process.

According to the classification process results, the media gateway should perform the necessary operations to convert the signals to IP according to the requirements of H.323.

Methods of compressing fax, modem and other data signals are for further study.

4.2 Voiceband Quality

See section 4.1.3 for handling of silence suppression and comfort noise generation. ITU-T Recommendation G.177 should be followed to ensure adequate end-to-end speech quality.


23

Definitions of categories of voice transmission quality may be found in ITU-T Recommendation G.109.

4.2.1 Tandem Free Operation

It is highly recommended that a single codec pair be used end to end.

High quality speech codecs operating at low to medium rates (4 to 16 kbps) have been a primary factor in making packet voice networks, including VoIP and Wireless networks practical. As different packet networks will be interfaced with one another, the tandeming of speech codecs will be very common in the near future. Tandem speech codecs may degrade speech quality considerably. As a result, many tandem free operation (TFO) standards have been developed under different standard organizations to avoid additional speech coding and decoding in a communication link. The TFO standards were based on the same approach and were originally intended for Wireless services. However, TFO standards are also applicable to any packetized networks including IP networks.

To avoid tandeming speech codecs and improve speech quality, a G.799.1 gateway should support the TFO protocol as defined in the following standards:

3GPP2 A.S0004-0.1, 3GPP2 Tandem Free Operation Specification, Version 1.0.0,

and

3G TS 28.062, Inband Tandem Free Operation (TFO) of Speech Codes; Stage 3 – Service Description

When G.799.1 gateways interconnect mobile networks using the first of these standards at one end and the second at the other end, interworking of the two TFO techniques is necessary. To provide high quality digitized voice services through seamless interworking across different networks, there is a need to consolidate these different TFO standards. This is a subject for further study.

4.2.2 Packet size selection

The choice of packet size is a trade-off between transport efficiency, quality and delay. The delay associated with codec processing and packetization should be kept as short as possible. Gateways should adhere to ITU-T Recommendation G.177 in this regard. When multiple frames of a speech codec are allocated to the same packet, packet loss concealment techniques become less effective and as a result may possibly lower end-to-end speech quality when packet loss is encountered.Packet size should be an integer multiple ofmatched to the codec frame length. To accomplish this objective when G.729 or G.729A is used, two frames per packet should be considered as the maximum packet size. Similarly, G.711 may be used with packet sizes of 10 ms (80 frames) or 20 ms (160 frames) to achieve this objective. Finally, when G.723.1 is used, only one frame should be included in each packet. The 7.5 ms look-ahead and the 30 ms frame size of G.723.1 results in a combined voice buffering and processing delay of between 37.5 ms and 67.5 ms (depending on the computational power available), thus contributing to difficulty of interactive communications.

The 30 ms frame size of G.723.1 results in voice collection and coding delay of at least 60 ms, contributing to difficulty of interactive communications.


24

4.3 Voiceband Data Quality

4.3.1 Voiceband data modems

Methods of ensuring quality operation with voiceband data modems are for further study.

4.3.2 Facsimile

Methods of ensuring quality operation with facsimile traffic are for further study.

4.3.3 Text telephones

Methods of ensuring quality operation with text telephones are for further study.

4.4 Switching

The TIGIN Gateway shall provide the ability to switch calls in the direction of the PSTN and in the direction of the IP network. Switch control based on general call control and allows establish, modify and release connection within the TIGIN.

Some details on methods of switching, and a discussion on switching philosophy are included in MSF-ARCH-001.00-FINAL IA “Multiservice Switching Forum Implementation Agreement” of the Multiservice Switching Forum.

Editor’s Note: The above reference document may become normative text depending on Q7’s conclusions on this issue following discussion on the Q7 discussion board and/or an interim meeting.

This item is for further study.

4.5 Conference Bridging

A TIGIN gateway is not required to support conference bridging.

4.6 Clock Recovery and synchronization

A TIGIN gateway requires a clock recovery circuit that would allow it to generate a precise local clock and keep this clock synchronised to a remote TDM clock. A synchronisation mechanism improves the quality of voice at the reception and it is vital for the transport of data through RTP trunking.

Timing information may be transported between two Circuit Switch domains:

over the IP network (using the timestamp mechanism provided by the RTP encapsulation)

other methods (e.g. those used for hierarchical timing distribution in SDH networks as specified in G.813, "Timing characteristics of SDH equipment slave clocks (SEC) ")

For interoperability reasons, TIGIN implementations which use methods for synchronising the local TDM clock based on timing information transported over the IP networks, should be based on information made available by the approved protocols rather then using proprietary schemes. Such information, for example, is the RTP timestamp (see RFC 1889). Methods of determining the resolution of the timestamp are for future study.


25

Similar to the case of hierarchical master-slave SCN synchronisation methods, it is recommended that a primary and a secondary synchronisation reference input be provided to each clock (e.g. two independent sources of IP/UDP/RTP packets that could be used for extracting timing information).

The remainder of this section is for information purposes only:

As described in IETF RFC-1889 the randomly initialised RTP timestamp is a 32-bit field that must be updated such that it reflects the sampling instance of the first octet in the RTP data packet. Consequently, there is a direct relation between the rate of the TDM clock at the sending TIGIN and the rate of the RTP packets being filled up, sent over the IP network, and, the rate of their arrival at the receiving TIGIN. At the receive end, the arrival of an RTP packet could be timestamped based on the TDM clock of the Circuit Switch domain interfacing to the local (receiving) TIGIN.

The difference between the packet arrival times and the difference between RTP packet timestamps could be algorithmically processed to extract information for adjusting the local TDM clock- see IETF RFC-2833-RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals.

4.7 Management System

The Management System Interface performs the functions to administer the system on a non-real time (non per-call) basis with respect to the following subsections. Further details for each of the management functions outlined in the following sub-sections are included in the general (e.g., ITU-T M.3100) and technology specific (e.g., ITU-T G.784, IETF RFC 2579) recommendations.

Support of TMN and SNMP management systems are for further study.

4.7.1 Configuration Management

For further study. Issues to be considered include the management of:

TDM interface features such as line rates, frame formats

IP interface features

Packetizer options such packet loss mitigation scheme, which are not needed to be controlled on a per call basis.

echo canceller options

Voice feature options

clock recovery

and all other configurable parameters

4.7.2 Fault Management

For further study. Issues to be considered include the management of:

Equipment faults

Facility faults at TDM and IP sides

4.7.3 Performance Management

For further study. Issues to be considered include:


26

Facility performance monitoring

Congestion control

Traffic management

4.7.4 Security Management

Security management including key management is for further study.

4.7.5 Accounting

No accounting functions are supported in a TIGIN gateway. Note that this does not imply that signals such as on-hook, off-hook, etc., that support or provide information necessary for certain accounting type functions (e.g., call billing) do not need to be conveyed or supported. Rather, that the TIGIN Gateway itself does not provide any direct accounting functionality such as call billing, etc.


27

4.7.6 Maintenance Testing

The TIGIN Gateway shall provide the ability to monitor calls and place test calls in the direction of the GSTN and in the direction of the IP network.

The monitor and intrusive access point shall provide a test access point on a per TIGIN Gateway basis and not on a per-shelf or per-rack basis, i.e., one per TIGIN Gateway. This test access capability shall support all features and services provided by the TIGIN Gateway.

4.7.6.1 Non-intrusive Monitor Access:

The monitor access shall provide the ability to connect to a specific port/address/call and monitor one or both directions of an active call simultaneously (figure 8). It shall be possible to monitor a specific port or connection within the TIGIN Gateway allowing a port to be monitored before a call is active on the port. When an active call is placed on the port, the monitor shall remain active. The monitor access may provide either/or a TDM or IP output and will depend on the actual implementation of the TIGIN Gateway.

In the non-intrusive monitoring case, there is no requirement that signalling be monitored.

Figure 8. Non-intrusive Monitor Access

4.7.6.2 Intrusive Monitor Access:

The intrusive test access shall allow test calls to be made in either direction. The intrusive test access shall allow the user to connect to a specific port/address and place a call to a destination either in the direction of the GSTN or the IP network. The intrusive test access may provide either/or a TDM or IP output and will depend on the actual implementation of the TIGIN Gateway.

In the case where the Test Access Port is TDM (e.g., Figure 9A), a TDM/IP conversion function is required to access the IP data port or stream.

The specific point within the IP path where access is placed should be the last IP point prior to any speech processing functions.


28

Figure 9A. Intrusive Test Access – TDM Test Access Port

In the case where the Test Access Port is IP (e.g., Figure 9B), a TDM/IP conversion function is required to access the TDM data port or stream.

The specific point within the TDM path where access is placed should be prior to any speech processing functions.

Figure 9B. Intrusive Test Access – IP Test Access Port

If TDM is provided, the interface shall be E1/T1 (G.703, G.704) and signalling shall be ISDN, CAS, R1, or R2, and V 5.2 (Q.931, G.704, Q.300 – Q.399, Q.400 – Q.499, and G.965). If an IP output is provided, the interface shall be as specified within section 3.1 of this document (G.799.1) and signalling shall be accomplished via H.248 signalling messages sent to/from the TIGIN Gateway as with any other IP port.


29

In the case of SS7 signalling arrangements, the signalling to set up calls is done via the H.248 path to the MGC.

The functions provided by the management system should not overlap with those provided by per call control.


30

Appendix I: Overview of the location of TIGIN gateways in end to end connections

Figure I1 shows a functional block diagram of transport network equipment for interconnecting GSTN terminals and IP Terminals (hereinafter abbreviated TIGIN).

Figure I1: Location of TIGIN and possible connection types of interest in this Recommendation. Four connection types are shown. See text for details.

The terminals attached to the Internet are assumed to have H.323 functionality from the point of view of voice and voice-band data transmission. These terminals may be connected to the IP network via a direct connection (e.g., Ethernet, Token Ring, etc.) or a dial-up connection (e.g., modem and PPP link). The IP and GSTN sections are interconnected through a GSTN/IP gateway, called a TIGIN. For convenience, this gateway is designated with a single box in Figure I1.

The specific functions of the gateway will depend on whether the direction of transmission is from the IP Network to the GSTN or vice versa. In particular, the functions in the gateway include (but are not limited to):

Call originating on the IP Network and terminating onà GSTN

Reception, interpretation and generation of relevant signalling messages

Packet disassembly (including “IP stack”)

Speech decoder (including error concealment, comfort noise, silence insertion, etc.)

Management or regulation of delay variation

Echo cancellation


31

Call originating on the GSTN and terminating on IP Network

Reception, interpretation and generation of relevant signalling messages

Speech encoder (including silence removal, comfort noise decisions, etc.)

Packet assembly (including “IP stack”)

Management or regulation of delay variation

Echo cancellation

Four connection arrangements are considered in this Recommendation, each of which is shown in Figure I1. They are:

1. GSTN Terminal à H.323 Terminal (GSTN Terminal à GSTN à TIGIN à IP Network à H.323 Terminal)

2. H.323 Terminal à GSTN Terminal (H.323 Terminal à IP Network à TIGIN à GSTN à GSTN Terminal)

3. H.323 Terminal à H.323 Terminal (H.323 Terminal à IP Network à TIGIN à IP Network à H.323 Terminal)

4. GSTN Terminal à GSTN Terminal (GSTN Terminal à GSTN à TIGIN à GSTN à GSTN Terminal)

Each of these four connection arrangements requires the use of one gateway. Hence, connections that are purely GSTN-based or are strictly H.323-to-H.323 using only the Internet are not the subject of this Recommendation. Situations in which multiple or tandem gateways are used are covered by combinations of connections 1 through 4 (e.g. a combination of 1 & 2 would be GSTN Terminal à GSTN à TIGIN #1 à IP Network à TIGIN #2 à GSTN à GSTN Terminal). More complex arrangements may be envisaged but it is not considered necessary to describe them in detail as they can be made up of these above cases.

Appendix II. Performance / Interworking

Performance / interworking issues include:

a. Ability to vary the packet size on a per call basis

Voice samples are accumulated and buffered into a packet, and a packet is sent when it becomes full. The size of the packet can be controlled by PCC messages, but the network must ensure that they are the same on both ends of a connection. In addition, the capability to vary the packet size on a per call basis must be supported by the PCC protocol, and is outside the scope of this of document.

b. Silence suppression / Comfort noise generation when used in conjunction with codecs that do not describe them.

c. Real time control protocol (RTCP)

d. Packet loss mitigation scheme


32

e. Jitter buffer size

Variation in the arrival of packets into the TIGIN (packet delay variation) must be accommodated by a jitter buffer. The size of the jitter buffer must be selected based on the quality goals for the network. In addition, the type of data being transported may affect the selection of the jitter buffer size. For example, voice transmission is tolerant to packet loss but not to excessive delay, whereas voice-band data or data is tolerant to delay but not to packet loss.

f. Transmission delay

Delay through the TIGIN should be minimized. In addition, the TIGIN should be tolerant to the overall delay produced by the network.

Appendix III: TIGIN Equipment Arrangements

The basic interworking arrangements between IP networks and GSTN networks is shown in the figure III.1:

Figure III.1/G.799.1 GSTN Terminal interworking with H.323 Terminal

Other cases may exist such as:


33

Figure III2/G.799.1 - GSTN Terminals interconnected through network optimized for transport of IP

or

Figure III3/G.799.1 - H.323 Terminals interconnected through GSTN Network

In the latter two cases, the interworking functions will remain the same so will not be dealt with further.


34

Equipment Arrangements including TIGIN

The equipment arrangements for TIGIN would be:

Figure III4/G.799.1 - Proposed IP/GSTN Equipment Arrangement

The Multiplex and Interoffice Transmission are optional depending on the relative locations of the IP and Telephony Switches.

_______________


Itu

Documents

Transcript of Itu