T-Packtiming

8/7/2019 T-Packtiming

1/30

Contact: Stefano RuffiniEricsson

Italy

Tel: + 39 06 7258 9892Fax:

Email: [email protected]: 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 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 ITU-T.

INTERNATIONAL TELECOMMUNICATION UNION STUDYGROUP15

TELECOMMUNICATION

STANDARDIZATION SECTOR

STUDY PERIOD 2005-2008

TD 147 (WP 3/15)

English only

Original: English

Question(s): 13/15 Geneva, 16-27 May 2005

TEMPORARY DOCUMENT

Source: Editor Recommendation G.pactiming

Title: Latest draft of G.pactiming

This document contains the latest draft of the Recommendation G.pactiming. This version of

the Recommendation was approved during the SG15/13 meeting, held in Geneva the 16-20May 2005.

ITU-T Recommendation G.pactiming

Timing and Synchronization aspects in Packet Networks

Summary

This Recommendation analyses synchronization aspects in packet networks and outlines theminimum requirements for the synchronization function of network elements.

Keywords

Synchronization, jitter, wander, clock

Introduction

1 Scope

This Recommendation analyses the synchronization aspects in packet networks and outlines the

minimum requirements for the synchronization function of network elements.

The packet networks that are in the scope of this recommendation will initially be limited to the

following scenarios (with increasing complexity):

Point-to-point Ethernet [IEEE 802.3] [16] Multipoint (bridged) Ethernet [IEEE 802.1] [15] Connection-oriented MPLS [IETF RFC 3031, ITU-T G 8110] [30]


2/30

- 2 -

TD 147 (WP 3/15)

Connectionless IP [IETF RFC 768 and RFC 791]Editors note: that last two bullets may not be covered in the first release of the G.pactiming.

2 ReferencesThe 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;

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.

The reference to a document within this Recommendation does not give it, as a stand-alone

document, the status of a Recommendation

[1] ITU-T Recommendation G.703 (2001), Physical/electrical characteristics of hierarchical

digital interfaces.

[2] ITU-T Recommendation G.783 (2004), Characteristics of synchronous digital hierarchy

(SDH) equipment functional blocks.

[3] ITU-T Recommendation G.801 (1988), Digital transmission models.

[4] ITU-T Recommendation G.803 (2000), Architecture of transport networks based on the

synchronous digital hierarchy (SDH).

[5] ITU-T Recommendation G.810 (1996), Definitions and terminology for synchronization

networks.

[6] ITU-T Recommendation G.811 (1997), Timing requirements of primary reference clocks.

[7] ITU-T Recommendation G.812 (2004), Timing requirements of slave clocks suitable for

use as node clocks in synchronization networks.

[8] ITU-T Recommendation G.813 (2003), Timing requirements of SDH equipment slave

clocks (SEC).

[9] ITU-T Recommendation G.822 (1988), Controlled slip rate objectives on an international

digital connection.

[10] ITU-T Recommendation G.823 (2000), The control of jitter and wander within digital

networks which are based on the 2048 kbit/s hierarchy.

[11] ITU-T Recommendation G.824 (2000), The control of jitter and wander within digitalnetworks which are based on the 1544 kbit/s hierarchy.

[12] ITU-T Recommendation G.825 (2000), The control of jitter and wander within digital

networks which are based on the synchronous digital hierarchy (SDH).

[13] TR 101 685 - Timing and synchronization aspects of Asynchronous Transfer Mode (ATM)

networks

[14] IEEE 802, IEEE standard for Local and Metropolitan Area Networks: Overview and

Architecture

[15] IEEE 802.1, MACBridging and Management

[16] IEEE 802.3, CSMA/CD access method and physical layer specifications


3/30

- 3 -

TD 147 (WP 3/15)

[17] ITU-T Y.1413, TDM-MPLS network interworking User plane interworking

[18] ITU-T Y.tdmip, TDM-IP network interworking User plane interworking

[19] ITU-T O.171, Timing jitter and wander measuring equipment for digital systems which are

based on the PDH

[20] ITU-T O.172, Timing jitter and wander measuring equipment for digital systems which arebased on the SDH

[21] TS 145 010, Digital cellular telecommunications systems (Phase 2+), Radio subsystem

synchronization

[22] TS 125.104, Universal Mobile Telecommunication Systems (UMTS), UTRA BS FDD, Radio

Transmission and Reception

[23] TS 125.105, Universal Mobile Telecommunication Systems (UMTS), UTRA BS TDD, Radio

Transmission and Reception

[24] TS 125.402, Universal Mobile Telecommunication Systems (UMTS), Synchronization in

UTRAN Stage 2

[25] ITU-T Draft Recommendation V.90, A digital modem and analog modem pair for use on

the Public Switched Telephone Network (PSTN) at data signalling rates of up to 56 kb/s

downstream and up to 33.6 kb/s upstream

[26] ITU-T T4 Standardization of Group 3 facsimile terminals for document transmission

[27] 3GPP2 C.S0010-B, Recommended Minimum Performance Standards for cdma2000 Spread

Spectrum Base Stations

[27] 3GPP2 C.S0002-C, Physical layer standard for cdma2000 Spread Spectrum Systems

[28] ITU-T G.8010, Architecture of Ethernet layer networks[30] ITU-T G.8110, MPLS Transport Network Architecture

[31] ITU-T G.701, Vocabulary of digital transmission and multiplexing, and pulse code

modulation (PCM) terms

[32] ITU-T Y.1411, ATM-MPLS Network Interworking - Cell mode user plane interworking

3 Definitions

Editors note:

Candidate terms to include here are for instance: Network-Synchronous Operation, ServiceSynchronization, Packet Network, TDM, IWF, CES, Packetizer, Depacketizer.

Network-synchronous operation: synchronization of the physical layer (usually by a timing

distribution of a timing signal traceable to a Primary Reference Clock PRC, see ITU-T G.811).

Editors note : to be checked if this definition is already covered in other relevant recommendation

(i.e. G.810, G.803)

Service Synchronization: synchronization of a specific service carried over a packet network.


4/30

- 4 -

TD 147 (WP 3/15)

TDM: See ITU-T Rec. G.701 [] [31]. Editors note: this is a preliminary definition. Further

contributions are invited.

Interworking Function (IWF): See ITU-T Rec. Y.1411 [32].

Differential Method: synchronisation of the end points of a packet based network using signalstraceable to a Primary Reference Clock (PRC) see ITU-T G.811 source. The PRCs at the end

points may be traceable to the same PRC thus operating in a synchronous mode of operation or may

be traceable to different PRCs thus operating in a pseudo-synchronous mode of operation.

Editors Note : a more generic term used for these methods is Methods based on Common Clock

which may not necessarily need to be a PRC. A formal definition is missing and should be added in

the G.pactiming.

4 Abbreviations

ATM Asynchronous Transfer Mode

CES Circuit Emulation Service

IWF Interworking Function

LLC Logical Link Control

MAC Medium Access Control

NTP Network Time Protocol

PDH Plesiochronous Digital Hierarchy

PRC Primary Reference Clock

RBS Radio Base Station

RTP Real-time Transport Protocol

SASE Stand Alone Synchronization EquipmentSDH Synchronous Digital Hierarchy

TDM Time Division Multiplex

5 Conventions

6 General

Packet switching was originally introduced to handle typically asynchronous data.

However, for new applications such as the transport of TDM service and the distribution ofsynchronization over packet networks, the strict synchronization requirements of those applications

must be considered.

In fact the ongoing evolution in telecommunications increases the likelihood of hybrid

packet/circuit environments for voice and voice band data services. These environments combine

packet technologies (e.g., ATM, IP) with traditional TDM systems. Under these conditions, it is

critical to ensure that an acceptable level of quality is maintained (e.g. limited slip rate).

Synchronization in TDM networks is well understood and implemented. Typically, a TDM circuit

service provider will maintain a timing distribution network, providing synchronization traceable to

a Primary Reference Clock (i.e., clock compliance with ref[6], ITU-T G.811). These arrangements

are described in industry requirements whereby network synchronization is derived from a PRC


5/30

- 5 -

TD 147 (WP 3/15)

source and distributed through network elements with lesser stratum clocks. An alternative solution

is to follow a distributed PRC approach (e.g. by using GPS).

Although the goal of the document is to cover the relevant packet network technologies, the timing

and synchronization aspects addressed in this document will initially concern with Ethernet based

networks with protocol layers as defined in IEEE 802.

Functional architecture for Ethernet networks are defined in ITU-T G.8010 [28].

In the context of the present document, the highest layers (e.g. layer 7 in OSI model) refer to

applications transported over the packet networks. Real time applications have relatively tight

timing requirements concerning delay and delay variation. Some applications might resolve their

timing issues within higher layers (e.g., MPEG2), other applications rely on the timing support

provided by one or more of the lower layers (e.g. physical layer).

The present document aims at describing different methods to obtain the synchronization related

requirements.

Additionally, the requirements for interfaces and equipment that are part of the Ethernet network,

are described. It also gives recommendations when to apply different types of synchronizationmethods.

Some considerations on applicable synchronization requirements in a packet based network are

summarized in the following subsections.

6.1 Packet Network Synchronization Requirements

The nodes involved in packet oriented transmission technology, (e.g. ATM network nodes) do not

require any synchronization for the implementation of the packet switching function. In fact at any

entrance point of a packet switch, an individual device shall provide packet timing adaptation (for

instance cell timing adaptation in case of ATM switch) of the incoming signal to the internal timing.

For instance in case of ATM network the principle to cater for frequency differences is to use idlecell stuffing. Transmission links therefore in principle need not to be synchronized with each other.

However, as network shall be able to integrate TDM-based application, when transporting a CBR

stream over a packet network and when interworking with PSTN networks, the packet network

shall provide correct timing at the service interfaces.

This means that the requirements on synchronization functions in packet networks, especially on the

boundary of the packet networks, are depending on the services carried over the network. For TDM

based services, the IWF may require network-synchronous operation in order to provide acceptable

performance.

6.2 TDM and SDH timing requirements

The transport of TDM signals through packet networks requires that the signals at the output of the

packet network still comply with TDM timing requirements, this is crucial to enable interworking

with TDM equipments.

These requirements are independent of the type of information transported by the TDM signal,

voice or data.

The adaptation of such signals is sometimes called Circuit Emulation Services (CES).

The timing requirements that are applicable are: jitter and wander limits at traffic and/or

synchronization interfaces, long term frequency accuracy as this can influence the slip performance

and total delay (which is critical for real time services as for instance voice service).


6/30

- 6 -

TD 147 (WP 3/15)

6.2.1 PDH timing requirements

The PDH timing requirements are mainly related to the jitter, wander and slip performance. In

particular the relevant requirements refer to the jitter and wander tolerance applicable at the input of

the network element at the boundary of a packet network that receives the TDM data and jitter and

wander generation applicable at the output of the network element generating TDM traffic at the

other end of the packet network. These values are specified in ITU-T G.823 for the network basedon 2048 kbit/s hierarchy and ITU-T G.824 for the network based on 1544 kbit/s hierarchy.

In addition the ITU-T G.822 specifying the slip rate objectives may be applicable. This is the case

when the clock of the equipment that generates the TDM signal and the clock used in the equipment

recovering the TDM signal from the packets are different.

6.2.2 Synchronization interfaces requirements

In case the PDH signals are defined as synchronization interfaces, the synchronization requirements

are more stringent than for 2048 kbit/s and 1544 kbit/s traffic interfaces. The synchronization

interface requirements for PDH interfaces are also defined in ITU-T G.823 and ITU-T G.824.

6.2.3 SDH timing requirements

Any STM-N signal must be compliant with ITU-T G.825. The relevant requirements refer to the

jitter and wander tolerance applicable at the input of the network element at the boundary of a

packet network that receives the STM-N data and jitter and wander generation applicable at the

output of the network element generating STM-N traffic at the other end of the packet network.

In case of STM-N signals there are no distinctions between traffic and synchronization interfaces as

all STM-N signals are defined to be as synchronization interfaces.

Editors note: STM-N CE is to be considered but probably this will not be done in the first release

of the G.pactiming. This is an important issue as STM-N is by definition a synchronization

interface. The impact on the existing assumptions on the hypothetical network reference model hasto be considered.

6.3 Synchronization Network Engineering in Packet Networks

The driving force for much of this work is to cater for the synchronization needs of the application

or in general the need of certain technologies (for instance Radio Base Station in GSM and

WCDMA networks). In order to achieve such goal, operators have therefore to distribute a

Reference Timing Signal of suitable quality to the Network Elements processing the application or

in general requiring accurate timing signal.

One approach is to follow a distributed PRC strategy (for instance by means of GPS technologies).

An alternative approach is based on a Master Slave strategy. The engineering rules for designing thesynchronization network in these cases are well understood and documented (see for example ITU-

T G.803, ref.4) when the underlying transport of the packets (e.g. IP frames) will run over the

existing synchronous technologies (PDH or SDH networks). On the other hand when the

underlying transport is based on non-synchronous technologies (i.e. Ethernet), alternative

approaches shall be considered. This will be further analysed in section 8, Reference Timing

distribution over Packet Network.

6.4 Timing requirements at edge versus timing requirements in core networks

Different performance can be requested in case the packet network is part of an access network or is

the underlying layer of the Core Network.


7/30

- 7 -

TD 147 (WP 3/15)

The distribution of a synchronization reference over a portion of a core network may be requested

to comply with strict jitter and wander requirements (i.e. G.823, G.824 for synchronization

interfaces and G.825).

On the other hand in the access network, requirements may be related to allow a distribution of a

timing reference signal with performance sufficient to support the timing requirements of the end

node (for instance a Radio Base Station, or a V90 modem).

6.4.1 Synchronization requirements for GSM, WCDMA and CDMA2000 Base Stations

(RBS)

The timing requirement applicable to the GSM radio interface can be found in the ETSI technical

specification TS 145.010 (ref.xx). The basic requirement is to fulfil 50 ppb frequency accuracy on

the radio interface.

The timing requirement applicable to the WCDMA radio interface can be found in the technical

specifications and TS 125.104 (FDD mode) (ref. xx) and TS 125.105 (TDD mode) (ref xx). Also for

the WCDMA the basic requirement is to fulfil 50 ppb frequency accuracy on the radio interface.

The WCDMA TDD mode puts additional requirements on the phase accuracy. The requirement on

the relative phase difference between Node Bs is to not exceed 2.5 s (see TS 125.402, ref xxx).

It should be noticed that for in case of GSM and WCDMA radio access network there are not so

strict frequency accuracy requirements related to limit the slip rate.

In fact in these cases the data of a single user is stored in relatively large buffer (from 10 to 30 ms)

and also assuming 50 ppb frequency accuracy the data would be lost (buffer empty or full) after

long times, much longer if compared with classical switching network elements where buffers

handling the data are much smaller (125 microsec.).

The relevant CDMA2000 standard is the 3GPP2 C.S0010-B. Concerning synchronization

requirements, it states that:

the timing of the base station shall be within 10s of UTC. the average frequency difference between the actual CDMA transmit carrier frequency and

specified CDMA transmit frequency assignment shall be less than 50 ppb

In addition according to 3GPP2 C S0002-B specification, in order to support the CDMA System

Time, all the base station digital transmissions are referenced to a common CDMA system-wide

time scale that uses the Global Positioning System (GPS) time scale, which is traceable to, and

synchronous with, Universal Coordinated Time (UTC).

6.4.2 Synchronization requirements for facsimile and voce band Modem applications

The timing requirements to be considered for the Facsimile and Modem applications are certainlynot so strict as for the GSM and WCDMA RBS, nevertheless these have to be considered when

moving the access network towards non-synchronous (e.g. Ethernet) environment.

There are many types of voice band modems but the high-speed types are likely to be most sensitive

to jitter. Two significantly different types exist: the QAM based modems e.g. V.34bis and the PAM

based V.90 and V.92.

The V-Series recommendations provide guidance regarding the maximum error allowed in the bit-

rate of the various voice-band modems used in the general public switched telephone network. The

limit is generally 0.01% (see for instance ITU-T Recc. V.90).

Assuming that modems can recover the timing from the incoming data, the frequency accuracyrequirement applicable to Network Elements connected to modems can therefore be specified to be


8/30

- 8 -

TD 147 (WP 3/15)

in the range of several ppm (up to 100 ppm) depending on the specific modem technology that shall

be supported.. However it should also be considered that an Access Device with frequency accuracy

deviating from the service frequency would create unacceptable data loss (buffer full or empty) and

frequency accuracy better than 100 ppm is therefore required.

The actual value is left for further study.

Editors note: The value of +/-50 ppb applicable to Access Device connected to modems is

proposed as initial proposal for discussion.

With respect to standards applicable to Facsimile application, ITU-T has published many

recommended standards for facsimile (FAX) transmission.

In particular ITU-T Recommendation T0 describes four FAX apparatus groups; Groups 1 through

4.

The T4 standard can probably be considered the most modern and the most important one. The T4

standard states that the modulation is based on ITU modem standards like V.27ter, V29 and V.34.

The assumption is therefore that the synchronization related requirements for modem applicationsare applicable for Facsimile applications as well.

Editors note: requirements for Access Device supporting fax and modems is probably covered in

other VoIP recommendations (IWG, H series); section 6.4.2 is therefore to be confirmed.

7 Packet Networks Reference Models

The packet network reference models that have been used to characterize the performance of the

packet networks in terms of packet delay variations are shown in the following figures:

model A in Figure 1 is related to applications with very strict delay and delay variation

requirements, model B in Figure 2 refers to scenarios with less strict packet delay variationrequirements.

Figure 1 Packet network reference model A (switched Ethernet network)


9/30

- 9 -

TD 147 (WP 3/15)

Figure 2 Packet network reference model B (switched Ethernet network)

Following cases have been considered:

Scenario 1: Switched Ethernet network, Best effort with over-provisioning (single queue) Scenario 2: Switched Ethernet network, Quality of service according to IEEE 802.1q, IEEE

802.1p (at least 2 queues, with one dedicated queue for handling real-time data and WFQ,

Weighted Fair Queuing, discipline)

Scenario 3: Switched Ethernet network, Quality service according to IEEE 802.1q, IEEE802.1p (with one queue dedicated for the handling of data used for timing recovery,e.g.Time stamps)

Editors note: It has to be confirmed if similar scenarios can be provided for IP Router network. In

this case similar models and approaches could be applicable.

Editors node: the traffic models have to be defined (see Appendix I for initial input). Contributions

are invited.

Based on the above models, the following parameters apply for the different cases:

Network model A Network Model B

Scenario 1 tbd tbd

Scenario 2 tbd tbd

Scenario 3 tbd tbd

Table 1/G.pactiming: Parameters for the relevant network models

Editors note: Contributions are invited to fill the table with the relevant parameters (e.g. Packet

delay variation, etc.).


10/30

- 10 -

TD 147 (WP 3/15)

8 Network Limits

The jitter and wander network limits currently specified in the relevant ITU-T recommendations

(i.e. ITU-T G.823 and ITU-T G.824) have to be fulfilled in all the scenarios that are relevant for this

recommendation.

In particular following jitter and wander limits apply to the TDM signal carried over the CES in thescenarios described in Annex A.

Case 1: is for further study. Case 2: Application A

The jitter and wander budget of the CES in this case is the difference between the 2048 kbit/s

network limit (see Fig1/G.823) and the 2048 kbit/s synchronization interface network limit

(see Fig10/G.823). As an example the wander budget over 24h for 2 048 kbit/s

synchronization interface reaches 12.7 s in this case.In case of 1544 kbit/s interfaces, the jitter and wander budget of the CES in this case is the

difference between the 1 544 kbit/s network limit (see Table2/G.82) and the 1544 Mbit/s

synchronization interface network limit (see Fig 3/G.824).

Case2 application BThe wander budget of the CES is only limited by the timing quality requested by the

application and not by the ITU-T G.823 and ITU-T G.824 specifications.

Note: this application is valid only for application with a single signal; if 2 signals are

received there might exist a differential jitter and wander between one signal and the clock

extracted from the other signal.

Case 3:When retiming is implemented at the output of the SDH islands, the amplitude of noise on thePDH output is that of a synchronization interface; this allows to increase the wander budget

up to that of case 2 application A in some configurations

9 Reference Timing Signal Distribution over Packet Networks

In order to fulfil the applicable synchronization requirements, it should be possible to distribute a

reference timing signal with proper phase stability and frequency accuracy characteristics.

Two main classes of methods are identified in this recommendation:

Plesiochronous and Network Synchronous methods, Packet based methods.

9.1 Plesiochronous and Network Synchronous Methods

The first class of methods refers to PRC distributed method (for instance based on GPS), or Master-

Slave method using a synchronous physical layer (e.g. STM-N), see figure 3. These methods are

widely implemented to synchronize the TDM networks.

It can be noticed that the latter option is not available in case of Ethernet networks, as the physical

layer in this case is not defined to be synchronous.


11/30

- 11 -

TD 147 (WP 3/15)

Figure 3- Distributed PRC and Master Slave methods

Editors note: it has been recognized that when G.811 quality is required, in some cases and for

limited parts of the network, it would be useful to have also the option to distribute timing via a

synchronous Ethernet; further study is needed (e.g. traceability, etc.).

9.2 Packet based Methods

The second class of methods relies on timing information carried by the packets (e.g. sending

dedicated Time Stamp messages as shown in figure 3; methods using two-way transfer of timing

information are also possible such as NTP).

In some cases (for instance transport layer not synchronous) this is the only alternative to a PRC

distributed approach.

Packet based Methods and related performances are under study.

Figure 4 Example of packet based method with timing distribution of the Reference Timing

Signal via Time Stamps

10 Timing Recovery for Constant Bit Rate services transported over Packet Networks

CBR (Constant Bit Rate) services (e.g. Circuit Emulated TDM signals) require that the timing of

the signal is identical on both ends of the packet network: this is handled by the IWF responsible to

deliver the constant bit stream.

The following operating methods are identified within this recommendation:

Time Stamp

Master Packet NetworkTime Stamp

Processing

Time Stamp

PRC Reference

Recovered Reference Timing Signal

Time Stamp

Master Packet NetworkTime Stamp

Processing

Time Stamp

PRC Reference

Recovered Reference Timing Signal


12/30


13/30

- 13 -

TD 147 (WP 3/15)

Adaptive Methodsin this case the timing can be recovered based on the inter-arrival time of the packets or

on the fill level of the jitter buffer. It should be highlighted that the method preserves

the service timing (Asynchronous Circuit Timing).

Figure 7 Example of Adaptive Method

Reference Clock available at the TDM end systemsthis is a trivial case, in fact in this case both the end systems have direct access to the timingreference, and therefore there is no need to recover the timing, the only aspect to consider is

to guarantee a proper interworking with the IWFs, for instance via a loop timing scheme

(see figure 8). An example when this scenario might apply is when two PSTNs are

connected via a packet network.

Figure 8 PRC reference timing signal available at the TDM end systems


14/30

- 14 -

TD 147 (WP 3/15)

Editors note: above figure shows the TDM transmitter and receiver being traceable to a PRC. This

is the case where transmitter and receiver are for example digital switches where there is a need to

control slips. However there are cases where the transmitter and receiver are not traceable to G.811

clocks, for example E3 or DS3 multiplexors.

Editors note : Further details on the above mentioned clock recovery methods should be provided

in the Appendix. Contributions are invited.

11 Impact of impairments in the packet network on timing distribution and service clock

recovery

Editors note: this section should provide the analysis of the impacts of the impairments in the

packet network (i.e. packet loss, burst packet loss, bad sequencing of packets, delay variation,

temporary network congestion, routing changes, low frequency components of packet delay

variations and errored packets) on the timing distribution and on the service clock recovery.

Contributions are invited on these topics (the work done within ANSI T1X1.3 and ETSI on theATM networks could be used as basis for this analysis).

Editors note: There is a common understanding thatPacket loss and packet misordering within

certain limits to be specified do not significantly affect clock recovery performance for any of the

methods presented in G.pactiming. Specifically, at levels at which the TDM transport service is

useable, packet loss (both uniform and bursty) and packet misordering have negligible effect on

clock recovery performance. Further contributions are required. There is also a common

understanding that Packet delay variation should not affect clock recovery performance for the

Common Clock method presented in G.pactiming. Further contributions are invited.

12 Impact of Network Clock Impairment on timing distribution and service clockrecovery

Editors note: this section should provide the analysis of the impacts of Network Clock Impairments

on the service clock recovery (e.g. Differential methods) and on the timing distribution.

Contributions are invited on these topics (the work done within ANSI T1X1.3 and ETSI on the

ATM networks could be used as a basis for this analysis).

12.1 Impairments for the Network Synchronous Operation methods

The clocks involved in the transport of TDM signals through a packet network are shown in

figure 9.


15/30

- 15 -

TD 147 (WP 3/15)

Figure 9: clocks involved in the transport of TDM signals through a packet network

These are:

- The clock that generates the TDM signal, PDH or SDH (clk1 in the figure)

It is considered that most signals are now synchronous; if not, the use of a network clock reference

in the depacketizer (i.e. clk3 in the figure) will raise severe problems.

-The clock that is used to generate the packets (clk2 in the figure)

This clock has no direct effect on the recovery of the right timing; it simply changes the duration ofthe packets but not their periodicity. In the example shown in figure this clock is traceable to a PRC.

-The clock at the depacketizer which retimes the TDM signal after the packet network

In order to have a correct timing in the output TDM signal, the clocks generating (i.e. clk1) and

retiming (i.e. clk3) the TDM signal have to be identical, otherwise slips will be generated.

In normal operation these clocks are locked to a reference timing signal that is traceable to a PRC.

However during failures conditions in the synchronization network these clocks may be locked to a

reference timing signal that is traceable to a clock operating in holdover mode. The requirements

on clocks that during failure conditions shall provide a suitable holdover are to be based on the

ITU-T G.822 slip performance objectives, and on ITU-T G.823 and ITU-T G.824 jitter and wander

network performances.

In case of the packetizer and depacketizer clock, the clock providing holdover function during

failures in the synchronization network may be either integrated in the IWF itself or available in the

site (for instance integrated in a transmission network element or in a SASE). It is the responsibility

of the network planner to provide the most suitable solution.

Summarizing, the network synchronous mode of operation requires either the introduction of

expensive clocks in the sink IWF or a system that allows to switch to another, better, mode in case

of loss of synchronization from the network clock (PRC).

In order to detect the periods of loss of synchronization some kind of supervision of the traceability

is needed (e.g. SSM).


16/30

- 16 -

TD 147 (WP 3/15)

13 Equipment synchronization related requirements

13.1 Traffic Interfaces

Following requirements have been taken from existing recommendations (eg. ITU-T G.823, ITU-T

G.824, etc.).

Editors note: the SDH interfaces are covered in the following subsections,although these may not

be in the scope of the first version of the G.pactiming.

13.1.1 Physical, electrical and optical characteristics

Physical and electrical characteristics of E0 (64 kbit/s), E11 (1544 kbit/s), E12 (2048 kbit/s)

interfaces, all PDH interfaces, 51840 kbit/s (STM-0) and ES1 (STM-1) interfaces shall comply with

requirements of ITU-T Recommendation G.703.

Physical and optical characteristics of OS1 (STM-1), OS4 (STM-4), OS16 (STM-16) interfaces

shall comply with requirements of ITU-T Recommendation G.957 (Tables 2/G.957, 3/G.957).

13.1.2 Jitter and wander generationEditors note: this has been recognized to be an issue being related to the budget that can be

allocated to the CES segment. The upper bound is defined in G.823 and G.824. The actual budget

that can be allocated to the CES segment is expected to be a fraction of the total budget in most of

the cases (see also section 8).

For information, details on the total network limits are provided below.

The peak-to-peak output jitter for networks based on 2048 kbit/s hierarchy at E0, E12, E22, E31,

E4 traffic interfaces shall comply with requirements of ITU-T Recommendation G.823 (clause 5.1).

The peak-to-peak output jitter for networks based on 1544 kbit/s hierarchy at E11, E21, 32064

kbit/s, E32, 97728 kbit/s traffic interfaces shall comply with requirements of ITU-T

Recommendation G.824 (clause 5.1).The peak-to-peak output jitter for SDH-based networks at ES1, OS1, OS4, OS16 traffic interfacesshall comply with requirements of ITU-T Recommendation G.825 (clause 5.1). The peak-to-peak

output jitter at 51 840 kbit/s traffic interface shall comply with requirements of ITU-T

Recommendation G.703 (clause 16.2).

The output wander limit for networks based on 2 048 kbit/s hierarchy at E12, E31, E4 traffic

interfaces shall comply with requirements of ITU-T Recommendation G.823 (clause 5.2).

The output wander limit for networks based on 1 544 kbit/s hierarchy at E11, E32 traffic

interfaces shall comply with requirements of ITU-T Recommendation G.824 (clause 5.2).

The output wander limit for SDH-based networks at 51 840 kbit/s, ES1, OS1, OS4, OS16 traffic

interfaces, according to ITU-T Recommendation G.825 (clause 5.2), shall comply withrequirements of ITU-T Recommendation G.823 (clause 6.2) for networks based on the 2048 kbit/s

hierarchy and ITU-T Recommendation G.824 (clause 6.2) for networks based on the 1544 kbit/s

hierarchy. These requirements are defined for synchronization interfaces (PRC, SSU, SEC) because

STM-N traffic interfaces are considered as synchronization interfaces.

13.1.3 Jitter and Wander tolerance

The input jitter and wander tolerance for networks based on 2048 kbit/s hierarchy at E0, E12, E22,

E31, E4 traffic interfaces shall comply with requirements of ITU-T Recommendation G.823 (clause

7.1).


17/30


18/30

- 18 -

TD 147 (WP 3/15)

13.2.3 Jitter and wander tolerance

The input jitter tolerance at T12, E12 synchronization interfaces, according to ITU-T

Recommendation G.823 (clause 7.2), shall comply with requirements of ITU-T Recommendation

G.812 (clause 9.2, Type I) for SSU interfaces and ITU-T Recommendation G.813 (clause 8.2,

Option 1) for SEC interfaces.

The input jitter tolerance at E11 synchronization interface, according to ITU-T RecommendationG.824 (clause 7.3), shall comply with requirements of ITU-T Recommendation G.812 (clause 9.2,

Types II and III) for SSU interfaces and ITU-T Recommendation G.813 (clause 8.2, Option 2) for

SEC interfaces.

The input wander tolerance at T12, E12 synchronization interfaces, according to ITU-TRecommendation G.823 (clause 7.2), shall comply with requirements of ITU-T Recommendation

G.812 (clause 9.1, Type I) for SSU interfaces and ITU-T Recommendation G.813 (clause 8.1,

Option 1) for SEC interfaces.

The input wander tolerance at E11 synchronization interface, according to ITU-T Recommendation

G.824 (clause 7.3), shall comply with requirements of ITU-T Recommendation G.812 (clause 9.1,

Types II and III) for SSU interfaces and ITU-T Recommendation G.813 (clause 8.1, Option 2) forSEC interfaces.

13.3 IWF synchronization function

In the context of the present document the IWF provides the necessary adaptations between TDM

and packets streams.

With reference to figure 10 below, the supported timing options for the Tx clock are:

Timing from recovered source clock carried by the TDM input (loop-timing or line-timing); Timing from the network clock (the network clock can be derived either from the physical

layer of the traffic links from the packet network or through an external physical timinginterface, e.g., 2 048 kHz);

Timing from a free running clock (it shall provide an accuracy according to relevantTDM/CBR service interface, e.g. 2 048 kbit/s shall comply to ITU-T Recommendation

G.703, 50 ppm);

Differential methods; Adaptive timing (including clock recovery using dedicated Time Stamps).

Depending on the services to be provided, a suitable subset of the listed timing options shall be

supported.

It is recommended to have slip control in the TDM Tx direction to control possible over/underflow

in the playout buffer. Slips shall be performed on n x 125 microsecond frames.

When TDM transmitter and/or receiver clocks are in holdover or are traceable to clocks in holdover,

and a synchronous clock recovery technique (Differential method or Network synchronous

operation) is used, slips (most likely uncontrolled) will occur. A back-up method based on the use

of adaptive method may be used in order to avoid an excessive rate of slips.

In the TDM-to-Packet direction, the synchronization related requirements are mainly depending on

the synchronization requirements of the physical layer. These are not detailed in the figure.


19/30

- 19 -

TD 147 (WP 3/15)

Figure 10 - IWF synchronization functions

Editors note: other subsection will be included in section 13 in order to cover all relevant

equipment synchronization requirements (noise transfer, latency, etc.) . Contributions are invited on

these topics.

14 Results and consequences of the different synchronization methods over Packet

Network Reference Models

Editors note: this section shall provide basic recommendations on how the synchronization shall bedistributed/recovered for the different Packet Networks models. The recommendations would

depend on the requirements to be fulfilled (for instance physical layer requirements -e.g. wander

and jitter at the traffic interfaces- or reference timing signal stability for distributing synchronization

reference to access nodes as RBSs). Contributions are invited on these topics.


20/30

- 20 -

TD 147 (WP 3/15)

Annex A

Network model underlying the network limits

For the transport of PDH signals the model in figure A1 of ITU-T G.823 is the starting point to

consider the insertion of CES segment (similar considerations are valid for G.824 limits, see figuresA1/G.824 and A2/G.824). The wander budget allocation for CES must be only a portion of the

entire wander budget as specified in G.823 or G.824, since the total wander budget has to be shared

with the rest of the network

Depending of where the CES is located different wander requirements may apply (see figure

below). Following types of CES have been identified:

Case 1: When the CES is located between the two switches of G.823 reference model, thewander budget is calculated based on model in figure A.1 below. The model is based on figure

A.1/G.823, from ITU-T G.823, where one of the SDH Islands is replaced by the CES network.Editors note: with this model the wander generated by the CES portion shall be not greater than

half of the G.823 limits. The assumption is to be confirmed through simulations using the packet

networks model from section 7 of this recommendation. The model is valid for networks based on

the 2048 kbit/s hierarchy. A similar approach could be provided for the networks based on the 1544

kbit/s hierarchy (see ITU-T G.824).

Figure A.1 - Network Models for data and clock wander accumulation (networks based on 2048

kbit/s hierarchy)

IWF IWFSDH

IslandSDH

Island

CES

Island

IWF

CES

Island

IWF

Wander and jitter

budget for the CES

Synchronization

networkSynchronization

network

PRC PRC

End

equipment

Wander and jitter

budget for the CES

IWF IWFSDH

IslandSDH

Island

CES

Island

IWF

CES

Island

IWF

Wander and jitter

budget for the CES

Synchronization


network

PRC PRC

End

equipment

Wander and jitter

budget for the CES


21/30

- 21 -

TD 147 (WP 3/15)

Case 2: Application AWhen the CES is located outside the 2 switches (see Figure A.2), the retiming effect of the switch

has to be considered. At the output of the switch, the timing of the G.823 signal has the quality of a

synchronization interface, mainly 2 Mbit/s synchronization interface. The jitter and wander budget

of the CES in this case is the difference between the 2048 kbit/s network limit (see Fig1/G.823) and

the 2048 kbit/s synchronization interface network limit (see Fig10/G.823). As an example the

wander budget over 24h reaches 12.7 s in this case.In case of 1544 kbit/s interfaces, the jitter and wander budget of the CES in this case is the

difference between the 1 544 kbit/s network limit (see Table2/G.82) and the 1544 Mbit/s

synchronization interface network limit (see Fig 3/G.824).

Case2 application BIn this case the application recovers timing through the TDM signal; therefore there is no

differential jitter and wander between the clock and the data other than within the bandwidth of the

clock recovery since the data and clock are extracted from the same signal. The wander budget of

the CES is only limited by the timing quality requested by the application (e.g. RBS requirements)and not by the G.823 specification.

Note: this application is valid only for application with a single signal; if 2 signals are received

there might exist a differential jitter and wander between one signal and the clock extracted from

the other signal.

Figure A.2: Case 1 and Case 2 scenarios

IWF IWFSDH

IslandSDH

Island

CES

Island

IWF

CES

Island

IWF

Case 2

Case 1

Synchronization


network

PRCPRC

End

equipment

IWF IWFSDH

IslandSDH

Island

CES

Island

IWF

CES

Island

IWF

Case 2

Case 1

Synchronization


network

PRCPRC

End

equipment


22/30

- 22 -

TD 147 (WP 3/15)

Case 3: When retiming is implemented at the output of the SDH islands, the amplitude of noiseon the PDH output is that of a synchronization interface; this allows to increase the wander

budget up to that of case 2 Application A in some configurations

Figure A.3: Case 3 scenario

The noise transfer characteristics of the CES have been identified to be an important issue.

Details on the measurement reference points are provided in figure A.4 (synchronized clock

configuration) and figure A.5 (independent clock configuration).

IWF IWFSDH

Island

SDH

IslandCES

Island

IWF

CES

Island

IWF

Case 3

Synchronization


network

PRC PRC

Endequipment

Synchronization

network

PRC

R

R = Retimer

IWF IWFSDH

Island

SDH

IslandCES

Island

IWF

CES

Island

IWF

Case 3

Synchronization


network

PRC PRC

Endequipment

Synchronization

network

PRC

R

R = Retimer


23/30

- 23 -

TD 147 (WP 3/15)

Figure A.4 Measurement reference points in the synchronized clock configuration

Figure A.5 Measurement reference points in the independent clock configuration

Editors note: the figures above do not cover all possible measurement scenarios. Further

contributions are invited.

Editors note: packet delay and packet delay variations formal definitions shall be introduced in the

G.pactiming. Contributions are invited.


24/30

- 24 -

TD 147 (WP 3/15)

Appendix I Characteristics of Ethernet switches and networks

Editors note: Expansions on the topics referred to in the body of this recommendation shall be

included in dedicated appendixes (e.g. details on clock recovery methods, introductory information

on Ethernet technologies, etc.).Editors note: this appendix provides initial information needed in order to build a network

reference model (to be defined in section 7). Further contributions on this subject are invited.

I.1 Delay Characteristics of Ethernet Switches

I.1.1 Functional Operations within an Ethernet Switch

From a black box perspective, an Ethernet frame passes through four functional operations in a

typical Ethernet switch. These are shown in Figure I-1:

Output

Port

Input

PortAdmission

Control

Switch

Fabric

Output

QueueClassifier

Figure I-1: Typical Functions within an Ethernet Switch

a. Classification identification of the flow to which the frame belongs, and determination ofthe output port and priority

b. Admission control application of traffic management for the flow (policing, shaping, marking)c. Switching forwarding to the appropriate output portd. Output queue waiting for a transmission slot on the output port. Typically queuing

policies such as strict priority, weighted fair queuing or round robin areapplied

The following sections discuss the delay properties of the various functions within a switch.

I.1.2 Input Stage Delay

The time required for the classification and admission control stages should be approximately

constant in most cases. However, depending on the switch design and the traffic loading on the

switch, the delay through these functions may vary. For example, in some switches, both

classification and admission control may be performed in software on a network processor. At full

load, the software may not be able to keep up with the number of frames to be processed, hence the

delay may increase, and some frame dropping may occur. The same may also be true of somehardware-based designs.

Figure I-2 shows a simplistic view of the variation of input stage delay with switch loading. Under

low traffic loads, the switch can cope with the number of frames passing through it without addingto the delay. As the frame rate increases, while the overall processing capacity of the switch is not

exceeded, the instantaneous frame rate may exceed the available processing rate. This will cause

frames to be buffered awaiting processing, and some extra delay to be incurred. Finally at some

point the mean incoming frame rate may exceed the processing capacity, causing the delay to be

increased further, and in some cases frames to be dropped due to lack of buffering capacity.


25/30

- 25 -

TD 147 (WP 3/15)

Intrinsic

propagation delay

Incoming

Frame Rate

Minimum intrinsic

propagation delay

No bufferingrequired

Buffering

required

Processing

overload

Figure I-2: Variation of Input Stage Delay with Loading

I.1.3 Switch Fabric Delay

The delay through the switch fabric itself is also dependent on both switch architecture and trafficloading. For example, many switches operate scheduling algorithms for switching of frames from

input ports through to output ports, and this may cause a small variation in delay to the frames,

depending on their arrival time relative to the scheduler tick. However, in most cases this

variation in delay is small due to the high frequency at which the scheduler works.

At very high incoming data rates, the switch fabric itself may be overloaded, and unable to cope

with the full volume of traffic requiring switching. This will result in frames being dropped.

I.1.4 Output Queuing Delay

The amount of delay added by the output queue will depend on the queuing policy employed, and

the priority of the traffic flow. For example, a high priority flow (such as might be used for apacket timing flow) in conjunction with a strict priority policy might experience head-of-line

blocking delay. This is where although a frame has highest priority, it arrives at the output port

just after a low-priority frame has started to be transmitted. The high priority frame then has to wait

until the other frame has finished transmitting.

Figure I-3 shows the delay profile experienced by a population of high priority frames in

conjunction with a strict priority queuing policy. For the purposes of simplicity, this diagram

assumes frames experience an approximately constant delay through the other switch functions,

here termed intrinsic propagation delay through switch. A proportion of frames arrive at the

output queue at a time when there are no other frames currently being transmitted. These frames are

transmitted immediately. The remainder have to wait in the queue while the current transmission

completes. There may also be an additional delay due to other high priority packets also in thequeue.


26/30

- 26 -

TD 147 (WP 3/15)

Frame delay

through switch

number of

frames

Transmission time of

maximum sized frame

Intrinsic propagation

delay through switch

Frames arriving when there are

no other frames being transmitted

subject to zero queuing delay

Head-of-line blocking - high priority

rames arriving when there is already a

low-priority frame being transmitted

Additional delay due to other

high priority frames in the queue

Figure I-3: Strict Priority Queuing: Head of Line Blocking

I.2 Characteristics of Switched Ethernet Networks

I.2.1 Topology of Ethernet Networks

Although there are many different possible network topologies, for the purpose of considering a

particular flow through a network, it can be modelled as a chain of Ethernet switches as shown in

Figure I-4. At each switch in the chain, an Ethernet frame has the potential to be delayed due to the

mechanisms described in section 0. This delay will be affected by the other traffic flowing through

the switch. Traffic directed to the same output port will affect the output queuing delay, while the

sum total of all traffic flowing through the switch (including that flowing to other ports) will affect

the processing and switch fabric delays.

Ethernet Switches

Network traffic routed to the

same output port

(affects output queuing delay)

Network traffic routed to

other output ports

(affects overload points)

Traffic flow ofinterest

Figure I-4: Data flows within an Ethernet Network

The length of the chain affects the total delay of the system; clearly the more switches there are, the

greater the total delay, also the greater the delay variation. However, in many Ethernet networks,

the length of the chain may be quite small. For example in a hierarchical network, there may often

be only two or three levels of hierarchy, yielding a chain length of up to five switches.

In some instances, a ring topology may be employed. Typically these may contain around ten

switches, giving a maximum distance around the ring of five switches. Occasionally,

interconnected rings may be used, which could double the distance to around ten.


27/30

- 27 -

TD 147 (WP 3/15)

I.2.2 Traffic Patterns and Levels

With the exception of constant bit rate and real time traffic, most network traffic is extremely bursty

in nature. It has been observed that on almost any level one cares to look, traffic variation can be

observed. For example, at a very small level there is bursting due to the opening and closing of the

TCP window size. At a larger level, there may be bursting due to the nature of the application (e.g.

downloads of large files), while at a larger level still there may be bursting due to the time of day(e.g. higher activity levels during the day than at night).

When considering the delay performance of a TDM transport flow, the effects of other traffic in the

network have to be considered. For example, in Figure I-4, each of the network traffic flows may be

varying in some form, independently of the other flows.

ITU-T Recommendation G.1020 proposes the use of four-state Markov models for modelling

packet loss distribution. A similar technique could be applied to burst lengths in each flow, allowing

bursts and groups of bursts to be modelled. The longer term (e.g. diurnal variation) could then be

applied as a gradual variation in burst densities.

I.2.3 Disruptive Events in Ethernet Networks

There are several types of disruptive events that may cause sudden changes in delay in an

Ethernet network. The resulting delay changes may be permanent or temporary. These disruptive

events include:

Routing change, causing a permanent step change in delay Temporary network overload, causing a significant but temporary delay change Temporary loss of service, causing all packets to be lost for a period


28/30

- 28 -

TD 147 (WP 3/15)

Appendix II Packet delay variation, Packet loss and congestion modelling

Editors note : the following information has been received from Q5/13 and has been agreed to be

the starting point for the modelling of packet loss and congestion:

Regarding network modelling for timing, the present state of the art is truncated Gaussian

distribution of delay variation, and extended Gilbert models for packet loss and congestion. The

former is somewhat unrealistic due to its high-pass nature in time, and can not model long range

correlations that make wander conformance difficult for purely adaptive recovery. The latter has

been shown to be a good match to true networks under a variety of conditions. Alternatively,

realistic network models that take routing mechanisms into account are also available, but require

precise definition of the network topology. To overcome this limitation one may define a small

number of network topologies as a standard test-bed.

For information, the Gilbert model is summarized in ITU-T G.1020 Appendix I.


29/30

- 29 -

TD 147 (WP 3/15)

Appendix III Functional diagrams based onITU-T G805 and G.809

The basic idea behind the functional description of TDM transport over Packet Switched Networks

(PSN) is that it is network interworking defining a client-server relationship between the TDMclient and the PSN server layer network. The IWF is technically an adaptation that accepts the client

TDM characteristic information and processes it to enable its transfer over a trail in the server

network. Hence the PSN forms a link connection supporting the TDM trail, providing a function

that could also be filled by an SDH or ATM network.

There are differences between the various cases. ITU-T Y.1413 details the connection-oriented

(CO) case, while Ethernet and IP networks are connectionless (CL) and need to be described in

terms of ITU-T G.809 diagrams (this work is presently being carried out in Q7/13 for Y.tdmip). As

examples, we diagram the simplest structure-agnostic TDM-over-MPLS and TDM-over-IP cases

below.

MPLS/

TDM

AP

TDM

TDM Network

MPLS/

TDM

TDM CPTDM CP

TDM

AP

MPLS MPLS

MPLS TCP MPLS TCP

TDM Network MPLS Network

MPLS

CP = Connection point AP= Access Point TCP= Termination Connection Point

Figure III-1: TDM transport over a CO PSN

Editors note: this appendix is preliminary and shall be checked with the relevant Questions toensure alignment with the other Ethernet recommendations.


30/30

- 30 -

TD 147 (WP 3/15)

IP/

TDM

IP AP

TDM

TDM Network

IP/

TDM

TDM CPTDM CP

TDM

IP AP

IP IP

IP TCP IP TCP

TDM Network IP Network

IP

CP = Connection point AP= Access Point TCP= Termination Connection Point

Figure III-2: TDM transport over a CL PSN

_____________

T-Packtiming

Documents