Migration from TDM to IP Network Made Simple

282018 February

IP vs TDM

Time-division multiplexing (TDM) was designed in early 50-s to carry voice calls. This technology reserves dedicated portion of network capacity for each voice connection, achieving constant delay during conversation. It is important, because humans are sensitive to delays during conversation. Unfortunately, reserved capacity cannot be used for other applications, if there is no voice traffic. That is one of the biggest TDM limitations, and technology of 50-s was not able to overcome it.

Ethernet network in turn does not ensure constant propagation delay, because latter is not required by most data applications. Thus, Ethernet and other packet-based networks make better utilization of available network capacity, as no part of total capacity is constantly reserved for voice calls.

Many operators still nowadays rely upon TDM networks as their transmission backbones, because these networks have reliably served over the years delivering voice, telemetry and data traffic. However, the future of communication networks is no doubt IP/MPLS, because TDM networks cannot support steadily increasing capacity demand by new applications.

Therefore, most network operators and utility providers running TDM networks are migrating their communication infrastructure to IP/MPLS now or at least are planning upgrades in the next years.

Microwave radio links are integral part

Any substantial network upgrade includes also replacement of MW radio links, which can be used both as network backbone or at least as partial network segments. In both cases upgrade must be done, keeping the disruption of existing services to a minimum. In most cases it is done gradually in several stages.

First, it is necessary to replace existing radio links with universal MW radio systems, which are capable to support TDM and IP traffic simultaneously. The new MW links must ensure transmission of all existing TDM traffic.

Second, the new parallel IP network infrastructure must be built over the whole existing network. This might require new Ethernet/MPLS switches, routers, optical transmission lines etc.

Third, migration from TDM to IP/MPLS traffic must be performed. TDM transmission over MW links can be gradually switched off during this stage, freeing up parts of total capacity and handing these over to IP/MPLS traffic.

What SAF Tehnika has to offer

Currently SAF Tehnika has two products suitable for TDM to IP/MPLS upgrade:

Both products incorporate native TDM traffic interfaces, in addition to Ethernet. However, frequency bands, capacities, traffic types and other features of products differ. As result, these products can support various target industries and applications. The following table illustrates key features, which are important, performing TDM to IP upgrade.

Customer requirements and features

PhoeniX G2

CFIP Marathon II

Radio spectrum availability

4, 6, 7, 11, 13, 18, 23 and 26 GHz

300 - 420 MHz
1.4 – 1.5 GHz

Channel bandwidth

7 – 60 MHz

250 kHz – 4 MHz or 1 - 8 MHz (depending on product version)

Maximum capacity, in 1+0 configuration

452 Mbps

20 or 43 Mbps
(depending on product version)

Traffic interface types

ASI, E1/T1 and Serial traffic is transmitted native, without Ethernet encapsulation. Only needed number of interfaces can be switched on.

  • Ethernet
  • ASI: 4 / 8 / 16 / 32 ports using external modules
  • E1/T1: 16 / 32 / 48 / 64 ports using external modules
  • Ethernet
  • E1/T1: 4 or 12 ports (depending on product version). Includes one E1/T1 port with fractional G.704 support
  • Serial v.24/v.28: 2 ports

Design type

Split mount solution:

Indoor Unit (IDU) +

Outdoor Unit (ODU).

Full indoor solution with no active components on the mast.

CFIP Marathon II

This product features many up-to-date technologies and legacy interfaces in one complete design. It can be used to replace legacy TDM links, working on low-frequency bands: 300 – 420 MHz and 1.4 GHz. The most differentiating features of this product are:

  • Narrow channels, starting from 250 kHz;
  • One E1/T1 port with fractional G.704 support;
  • Optional Serial v.24/v.28 interface.

Scenario: You need to transmit E1 stream over MW link, where only 3 time-slots contain payload, let’s say, TS03, TS06, TS21. You can use unframed E1 channel for transmission, and it will take about 2048 Kbps of total link capacity.

Using CFIP Marathon II fractional E1 feature instead, you can choose only needed number of time-slots for transmission. Such setup is shown on Fig. 1 below. Considering, TS0 is used for signaling, it will result in used capacity 4 x 64 = 256 Kbps. You will save 2048 – 256 = 1792 Kbps for other data, what is very important in case of narrow channel transmission.

Fig. 1 Fractional E1 menu of CFIP Marathon II

The most popular CFIP Marathon II applications are listed below with exact product features that are ensuring them.

  • Utilities

Utility corporations have been using legacy telecommunication infrastructure for years. It often contains remote terminal units monitoring and controlling information flows through hardwired serial connections that rely on fixed endpoints. Planned upgrades of communication infrastructure must support growing capacity demands for future smart grid/smart utility projects. IP migration must support supervisory control and data acquisition (SCADA) programs and add more flexibility handling corporate data and other traffic.

CFIP Marathon II Serial version is designed especially for customers, who are planning an IP upgrade but want to maintain legacy-networking equipment, industrial machines and expensive measuring instruments, which rely on serial interface type. Customers can easily perform an IP upgrade without interrupting operation of legacy equipment connected via serial interface.

Network security and reliability are key issues during IP migration, because IP network is more vulnerable against attacks than legacy TDM networks. CFIP Marathon II supports various Ethernet features for traffic separating and prioritization as VLANS, and QoS, thus helping to separate mission-critical and non-mission-critical data. Upon Utilities customers’ requests, we implemented also RADIUS server support for maximum secure authorization process.

  • Public safety

Fire, police and ambulance services operate private communication networks for which they need mission-critical equipment. Whether to interconnect mobile radio stations or to establish a private network with central command and control locations, CFIP Marathon II with advanced Ethernet features as RSTP protocol allows building secure and self-healing network topologies. It serves as ideal backbone for most popular public safety communication networks as LMR, DMR and TETRA. These networks often use E1/T1 infrastructure. The Fractional E1 feature of Marathon II allows transmitting only as much frames as needed thus sparing link capacity for other traffic, improving link budget, and immunity.

  • Oil & gas

The vital need of Oil & gas companies is reliable and cost-effective communication between offshore platforms, moving vessels and terrestrial locations. CFIP Marathon II radio is the perfect solution for oil & gas companies to build highly reliable 1+1 (Space Diversity, FD, HSB) protection mechanisms over water or desert to control and monitor their mission-critical applications.

  • Transport

For road networks, railroads, canal systems and airports it is substantially necessary to use a safe and reliable voice and data communications equipment. Again, most popular are LMR, DMR, and TETRA networks, where CFIP Marathon II fits perfectly. With wide areas to cover, often over long distances and with challenging terrains, a robust, well performing, and cost-effective solution is essential. CFIP Marathon II high system gain and 1.4 GHz frequency band allows building long-distance links - up to 100km and more.

PhoeniX G2

More information on the PhoeniX G2 will be available in an upcoming April blog post. Make sure you subscribe to our blog by clicking on the button below.

SUBSCRIBE
prev post
next post

Egils Viskints

view all posts