Lanode.com

  • Increase font size
  • Default font size
  • Decrease font size
Home News & Views Viewpoints Clocks in TDM over IP Networks

Clocks in TDM over IP Networks

E-mail Print

Clocks, clock recovery, synchronisation and Multicast issues when migrating leased lines from a traditional PDH/SDH network to a packet-based one.

In this 'Viewpoint' we explain some of the clocking and synchronisation issues associated with migrating traditional leased lines to a packet network, largely from a carrier’s perspective.

These issues are not always apparent before a system is deployed and can cause tremendous problems if not considered and addressed prior to roll-out.

Firstly a brief mention of clocks and accuracy:

  1. Different manufacturers of CESoP or TDM over IP products employ different methods of clock recovery (where one end of a link has a clock source and at the other end of the packet network this clock has to be extracted from the data in some way so as to provide a clock for the remote end). These clock recovery processes provide very different results and are a key differentiator between products.
  2. The importance of the clock recovery and its accuracy varies from customer to customer, application to application and network topology to topology. To some the accuracy/stability will not be important; to others it will be critical.
  3. Not providing an accurate, stable synch clock generally results in slips and data loss. The data loss will normally either be a packet, or if the jitter buffer has to “vent” it will potentially be many packets. Loss of this amount of data has been shown to cause PRIs and E1 interfaces to shut down as they lose significant data in their timeslot zero timing/synch channel. Generally the customer will experience a far higher loss of data than when using their previous leased line.
  4. Not having good synchronisation between mobile base stations is a major problem as calls are lost when handing-over between cells.
  5. Other more general issues such as what happens when there is a loss of service across the packet network; how does the clocking then react and what happens to the leased line on failure and recovery.

The importance of G.823 Synch:

It is worth noting that many carriers provide traditional leased lines that are specified to the G.823 Synch Mask (not the G.823 Traffic or Jitter Mask which are much looser and largely irrelevant Specs).

When migrating leased lines to a packet network, informed customers will often question clocking, synchronisation and degradation in performance/quality. If the carrier can deliver the new packet-based services and meet the original G.823 Synch interface then these potential questions and support problems disappear.

Realising the importance of G.823 some manufacturers will claim compliance to the G.823 specification, where in reality compliance is only relating to specific and individual subsections of the document. The specific parts that are commonly quoted are those relating to the Jitter and Wander tolerance of the actual interface and not compliance to the MTIE/TIE clock accuracy/stability elements. The tolerance to Wander/Jitter does not bear any relationship to the recovered clock performance, which is of course the key requirement in circuit emulation over IP type products.

Transition Network's high-quality clock recovery processes enable the G.823 MTIE Synch Mask to be met on high quality networks, and this can even be achieved over larger distances with many switch/router hops which tend to make accurate clock recovery harder to achieve.

Meeting the G.823 MTIE Synch requirements should be the key target of the service provider to give both confidence to customers, and to greatly reduce quality problems and the resulting tech support issues. It also makes meeting SLAs achievable.

Different types of leased lines:

  1. G.703 – these are generally supplied without clocks from the carrier and the user configures some kind of clocking hierarchy. Although these circuits are not clocked by the carrier, they will still need to have accurate, stable and synchronised clocks at each end of the link. Some G.703 circuits are provided by the carrier as a clocked circuit.
  2. G.704 – channelised circuits from a carrier, perhaps where multiple remote V.35/X.21 low-speed circuits are delivered to a central site in a G.704, are normally clocked by the carrier.
  3. V.35 and X.21 leased lines are always clocked by the local exchange.

Migrating the above 3 circuit types to a packet network does have potential issues and these are covered below.

Different types of networks:

Two main customer topologies are of interest to a carrier migrating DDN leased lines to a packet network, but there are alternatives within these:

1. A network where there is a central site inter-connecting to multiple remote sites:

a). In many instances this larger central site will have some clock source, either sourced via another circuit from the carrier or some owned clock generator (such as a rubidium PRC – Primary Reference Clock). In this example the remote sites can recover the central clock for their attached devices.

b). If, however, the remote sites are some distance away from the central site, multiple hops through the network can have an adverse effect on the clock recovery processes. This means the recovered clock is perhaps not as accurate as may be needed. Some applications are very sensitive to the accuracy and stability of clocks (for example back-haul for mobile applications).

2. A network or circuit where there is no central site, the customer has simple point-to-point lines or maybe a V.35 circuit between two places:

a). When delivering V.35 circuits via DDN the local exchanges (which are in effect locked to a common clock) provide clocks across the V.35 to the customer and the customer expects to be clocked. When moved to a packet network, where will the clocks come from? There is no network clock and the customer has no clock source.

b). In a situation where the customer has multiple circuits terminating at one site, these will often connect to a single piece of equipment. If these circuits do not share a common clock there will be data loss and synch issues.

PacketBand viewpoint schematic 1

NB: Illustrates Data Links between sites where there is no clock source. Clocks are Multicast from a central site

The ability to provide accurate clocks in all of the above situations is vital to maintaining quality services and SLAs.

Recovering Clocks:

  1. In a simple “star” network where all remote sites are clocked from a central site, the clocking architecture is simple. However, depending upon application the accuracy of the recovered clock may or may not be critical, depending upon application.
  2. In a more complicated network where sites have links between different locations, each of these circuits must be closely aligned, even if they come from different locations or clock sources. If they are not aligned accurately then clock slips can occur with the resulting loss of data.
  3. In many instances, moving to a packet network can leave the CESoP devices isolated from any clock source and therefore have to use an internal clock. PacketBand’s internal oscillators are very high quality and far better than most, but even these are not as good as a network-derived clock. Furthermore, running two separate circuits (which are using non- networked clocks) into the same customer equipment will mean having different clocks and therefore slips/hits.

Transition Networks Europe (Patapsco) PacketBand via Lanode:

The PacketBand has several clocking options to help with the above issues:

  1. Firstly, the standard clock recovery processes and on-board oscillators (the quality of which has a profound effect on recovered clock stability) are of the highest quality and sophistication. The recovery algorithms can be tuned to match the performance of the network and the best possible clocks will be provided. On good quality networks the G.823 MTIE Synch specification can be met.
  2. On larger networks with many hops, even the PacketBand may not quite meet the G.823 MTIE Synch requirements. For this type of application (and others; see below), Patapsco have developed a system whereby the clock recovery process is separated from the user data. This means a clock located in the same part of the country can be used for synchronisation to provide a highly efficient and resilient service using Multicast processes. This system also has network design advantages as the user data (which forms the bulk of the network traffic) is no longer used for clock recovery and can therefore be set at a lower QoS level.
  3. For circuits where no network clock is available the above-mentioned Multicast system can also be used. This ensures all circuits are completely synchronised.

PacketBand viewpoint schematic 2

NB: Regional clock sources provide high quality clocks to the local devices insuring stable and accurate synchronisation in even the largest networks.

Solution:

The PacketBand can deliver a very high quality service by recovering clocks across the packet network. We would gladly put the PacketBand up against any other solution for comparison; we know it works extremely well. However, for carriers who have little or no control, over a customer’s network design and attached equipment, there will be many instances where the common methods of recovery will either not work, or where an improved quality of service could be provided.

Implementing the Multicast solution covers all of the above-mentioned situations and means the carrier can deliver a high-quality transparent service to customers. This service means all devices are synchronised together no matter what the customer network requirements.

Hardware:

When using the Multicast option the carrier locates low-cost single E1 PacketBands regionally around the network. These provide a low-speed feed into a network switch with support for Multicast (IGMP). Customer-premise PacketBands must be preconfigured with the low-cost Multicast option. This enables then to join a Multicast and to use this service for accurate clocking. Remote units can be configured to access Secondary or Tertiary Multicast services for resiliency purposes.

The remote units then establish user data links between the appropriate end-points for transportation of the user data independently of the clock recovery data stream.

Overall there is little additional cost to implementing the Multicast system but it has numerous advantages and will deliver high quality clocks in all situations.

Please note that the non-Multicast PacketBand solution still delivers better clocks than any other currently available system.

Summary:

Enabling the integration of legacy equipment into modern IP networks thereby optimising the existing network infrastructure and supporting systems when expenditure is under such scrutiny, is a challenge that many organisations face. The reality is we need to 'squeeze' every last drop out of existing technology or better still, find technically advanced solutions that save us money now! One such technology is TDM over IP (Time Division Multiplexing over a packet switched network such as IP), with the ability to deliver clock-locked switched data channels across packet networks thus allowing E1 and serial based devices to communicate over Ethernet / IP networks.

Add to the mix the fact that BT will deprecate their Kilostream and Megastream services in the next few years then its encouraging to know that help is at hand with our PacketBand range of TDM over IP products which enable our customers to emulate their own kilostream or megastream circuits over corporate IP networks. In effect PacketBand-VX offers a simple migration of an existing system that utilises Kilo/Mega stream so you don't need a redesign of any network element to accommodate the demise of Kilo/Mega stream - you simply insert Packetband. You can also save money by being able to terminate the service and no longer have to pay BT Kilo/Mega stream line rental.

Source: This article has been used with the kind permission of Transition Networks Europe (Formerly Patapsco Communications)


Clocks, clock recovery, synchronisation and Multicast issues when migrating

leased lines from a traditional PDH/SDH network to a packet-based one.

 

The following explains some of the clocking and synchronisation issues associated with migrating traditional leased lines to a packet network, largely from a carrier’s perspective.

 

These issues are not always apparent before a system is deployed and can cause tremendous problems if not considered and addressed prior to roll-out.

 

Firstly a brief mention of clocks and accuracy:

 

  1. Different manufacturers of CESoP or TDM over IP products employ different methods of clock recovery (where one end of a link has a clock source and at the other end of the packet network this clock has to be extracted from the data in some way so as to provide a clock for the remote end). These clock recovery processes provide very different results and are a key differentiator between products.

  2. The importance of the clock recovery and its accuracy varies from customer to customer, application to application and network topology to topology. To some the accuracy/stability will not be important; to others it will be critical.

  3. Not providing an accurate, stable synch clock generally results in slips and data loss. The data loss will normally either be a packet, or if the jitter buffer has to “vent” it will potentially be many packets. Loss of this amount of data has been shown to cause PRIs and E1 interfaces to shut down as they lose significant data in their timeslot zero timing/synch channel. Generally the customer will experience a far higher loss of data than when using their previous leased line.

  4. Not having good synchronisation between mobile base stations is a major problem as calls are lost when handing-over between cells.

  5. Other more general issues such as what happens when there is a loss of service across the packet network; how does the clocking then react and what happens to the leased line on failure and recovery.

 

The importance of G.823 Synch:

 

It is worth noting that many carriers provide traditional leased lines that are specified to the G.823 Synch Mask (not the G.823 Traffic or Jitter Mask which are much looser and largely irrelevant Specs).

 

When migrating leased lines to a packet network, informed customers will often question clocking, synchronisation and degradation in performance/quality. If the carrier can deliver the new packet-based services and meet the original G.823 Synch interface then these potential questions and support problems disappear.

 

Realising the importance of G.823 some manufacturers will claim compliance to the G.823 specification, where in reality compliance is only relating to specific and individual subsections of the document. The specific parts that are commonly quoted are those relating to the Jitter and Wander tolerance of the actual interface and not compliance to the MTIE/TIE clock accuracy/stability elements. The tolerance to Wander/Jitter does not bear any relationship to the recovered clock performance, which is of course the key requirement in circuit emulation over IP type products.

 

Patapsco’s high-quality clock recovery processes enable the G.823 MTIE Synch Mask to be met on high quality networks, and this can even be achieved over larger distances with many switch/router hops which tend to make accurate clock recovery harder to achieve.

 

Meeting the G.823 MTIE Synch requirements should be the key target of the service provider to give both confidence to customers, and to greatly reduce quality problems and the resulting tech support issues. It also makes meeting SLAs achievable.

 

Different types of leased lines:

 

  1. G.703 – these are generally supplied without clocks from the carrier and the user configures some kind of clocking hierarchy. Although these circuits are not clocked by the carrier, they will still need to have accurate, stable and synchronised clocks at each end of the link. Some G.703 circuits are provided by the carrier as a clocked circuit.

  2. G.704 – channelised circuits from a carrier, perhaps where multiple remote V.35/X.21 low-speed circuits are delivered to a central site in a G.704, are normally clocked by the carrier.

  3. V.35 and X.21 leased lines are always clocked by the local exchange.

 

Migrating the above 3 circuit types to a packet network does have potential issues and these are covered below.

 

Different types of networks:

 

Two main customer topologies are of interest to a carrier migrating DDN leased lines to a packet network, but there are alternatives within these:

 

  1. A network where there is a central site inter-connecting to multiple remote sites:

      1. a). In many instances this larger central site will have some clock source, either sourced via another circuit from the carrier or some owned clock generator (such as a rubidium PRC – Primary Reference Clock). In this example the remote sites can recover the central clock for their attached devices.

b). If, however, the remote sites are some distance away from the central site, multiple hops through the network can have an adverse effect on the clock recovery processes. This means the recovered clock is perhaps not as accurate as may be needed. Some applications are very sensitive to the accuracy and stability of clocks (for example back-haul for mobile applications).

 

  1. A network or circuit where there is no central site, the customer has simple point-to-point lines or maybe a V.35 circuit between two places:

a. When delivering V.35 circuits via DDN the local exchanges (which are in effect locked to a common clock) provide clocks across the V.35 to the customer and the customer expects to be clocked. When moved to a packet network, where will the clocks come from? There is no network clock and the customer has no clock source.

b. In a situation where the customer has multiple circuits terminating at one site, these will often connect to a single piece of equipment. If these circuits do not share a common clock there will be data loss and synch issues.

 

 

 

 

 

 

 

 

 

 

 

 

NB: Illustrates Data Links between sites where there is no clock source. Clocks are Multicast from a central site

 

The ability to provide accurate clocks in all of the above situations is vital to maintaining quality services and SLAs.

 

Recovering Clocks:

 

  1. In a simple “star” network where all remote sites are clocked from a central site, the clocking architecture is simple. However, depending upon application the accuracy of the recovered clock may or may not be critical, depending upon application.

  2. In a more complicated network where sites have links between different locations, each of these circuits must be closely aligned, even if they come from different locations or clock sources. If they are not aligned accurately then clock slips can occur with the resulting loss of data.

  3. In many instances, moving to a packet network can leave the CESoP devices isolated from any clock source and therefore have to use an internal clock. PacketBand’s internal oscillators are very high quality and far better than most, but even these are not as good as a network-derived clock. Furthermore, running two separate circuits (which are using non- networked clocks) into the same customer equipment will mean having different clocks and therefore slips/hits.

 

Patapsco PacketBand:

 

The PacketBand has several clocking options to help with the above issues:

 

  1. Firstly, the standard clock recovery processes and on-board oscillators (the quality of which has a profound effect on recovered clock stability) are of the highest quality and sophistication. The recovery algorithms can be tuned to match the performance of the network and the best possible clocks will be provided. On good quality networks the G.823 MTIE Synch specification can be met.

  2. On larger networks with many hops, even the PacketBand may not quite meet the G.823 MTIE Synch requirements. For this type of application (and others; see below), Patapsco have developed a system whereby the clock recovery process is separated from the user data. This means a clock located in the same part of the country can be used for synchronisation to provide a highly efficient and resilient service using Multicast processes. This system also has network design advantages as the user data (which forms the bulk of the network traffic) is no longer used for clock recovery and can therefore be set at a lower QoS level.

  3. For circuits where no network clock is available the above-mentioned Multicast system can also be used. This ensures all circuits are completely synchronised.

 

 

NB: Regional clock sources provide high quality clocks to the local devices insuring stable and accurate synchronisation in even the largest networks.

 

Solution:

 

The PacketBand can deliver a very high quality service by recovering clocks across the packet network. We would gladly put the PacketBand up against any other solution for comparison; we know it works extremely well. However, for carriers who have little or no control, over a customer’s network design and attached equipment, there will be many instances where the common methods of recovery will either not work, or where an improved quality of service could be provided.

 

Implementing the Multicast solution covers all of the above-mentioned situations and means the carrier can deliver a high-quality transparent service to customers. This service means all devices are synchronised together no matter what the customer network requirements.

 

Hardware:

 

When using the Multicast option the carrier locates low-cost single E1 PacketBands regionally around the network. These provide a low-speed feed into a network switch with support for Multicast (IGMP). Customer-premise PacketBands must be preconfigured with the low-cost Multicast option. This enables then to join a Multicast and to use this service for accurate clocking. Remote units can be configured to access Secondary or Tertiary Multicast services for resiliency purposes.

 

The remote units then establish user data links between the appropriate end-points for transportation of the user data independently of the clock recovery data stream.

 

Overall there is little additional cost to implementing the Multicast system but it has numerous advantages and will deliver high quality clocks in all situations.

 

Please note that the non-Multicast PacketBand solution still delivers better clocks than any other currently available system.

 

Summary:

 

Enabling the integration of legacy equipment into modern IP networks thereby optimising the existing network infrastructure and supporting systems when expenditure is under such scrutiny, is a challenge that many organisations face. The reality is we need to 'squeeze' every last drop out of existing technology or better still, find technically advanced solutions that save us money now! One such technology is TDM over IP (Time Division Multiplexing over a packet switched network such as IP), with the ability to deliver clock-locked switched data channels across packet networks thus allowing E1 and serial based devices to communicate over Ethernet / IP networks.

 

Add to the mix the fact that BT will deprecate their Kilostream and Megastream services in the next few years then its encouraging to know that help is at hand with our PacketBand range of TDM over IP products which enable our customers to emulate their own kilostream or megastream circuits over corporate IP networks. In effect PacketBand-VX offers a simple migration of an existing system that utilises Kilo/Mega stream so you don't need a redesign of any network element to accommodate the demise of Kilo/Mega stream - you simply insert Packetband. You can also save money by being able to terminate the service and no longer have to pay BT Kilo/Mega stream line rental.

 

Source: This article has been used with the kind permission of Transition Networks Europe (Formerly Patapsco Communications)

 

How can we help?

Search

Live Demo of FRM220 Chassis

Related Products