Ethernet-Based Wireless Backhauling

Moving from Sonet/SDH and PDH into Ethernet as the transport infrastructure involves solving many critical issues, including network synchronization, support for TDM applications such as voice, use of the available lines and physical infrastructure, and interworking with existing networks, systems, and legacy backhauling networks.

The first challenge in the list, network synchronization, has been covered exhaustively over the last couple of years. While the Sonet/SDH and PDH networks enable frequency synchronization due to their nature (e.g., being synchronous or plesynchronous networks), this is not the case with Ethernet. Also, wireless backhauling is seeing a new demand to supply time synchronization (for roaming) too.

Many solutions were offered to deal with these requirements, ranging from software-based methods for distributing clocks (1588, NTP) to moving from Ethernet to Synchronous Ethernet (similar to Sonet/SDH networks and systems). While none of these solutions are perfect and some are missing parts, this challenge is mostly “solved.” Only time and maturity are needed before these solutions are established and deployed.

The second challenge in the list, support for TDM applications such as voice , mostly was dealt with when ATM was introduced into wireless backhauling in 3G. So, no major challenge or leapfrog is needed to move to Ethernet. By its nature, ATM does fit better with carrying voice (or, for that matter, TDM and real-time applications). But the difference isn’t major , and we can expect the same ideas and algorithms to work with Ethernet transport just as well.

Moving away from TDM voice to Voice over Internet Protocol (VoIP) will provide a complete solution to this issue. But even without it, the traffic engineering (TE) and quality of service (QoS) mechanisms available in Ethernet and multi-protocol label switching (MPLS) networks will handle these problems quite well.

Moving to the next challenge in the list, using the available lines and physical infrastructure, m any of today’s base stations are connected to the network with T1s/E1s lines. Additionally, and this also is true for newly installed base stations, legacy PDH lines still represent the most cost-effective way to connect them to the network. Yes, one can dream about installing optical Ethernet (or, for that matter, any type of Ethernet) everywhere. But this isn’t achievable in most cases, and it’s completely out of reach for many existing basestations and Node Bs.

Some may argue that the best solution is not to do anything with the existing systems and leave them as is with the existing Sonet/SDH and PDH infrastructure and lines. Another option would be to try to move only a portion of the network to Ethernet while leaving the basestations and Node Bs to use whatever is available for them and introduce Ethernet to the network closer to the core networks or somewhere between the access and the core. Both approaches are valid, and many carriers will adopt them.

Another alternative is to deploy the relatively new standard of Ethernet over PDH. It allows similar techniques as Ethernet over Sonet/SDH, which can be used over PDH lines (DS1, E1, and DS3 ). The standard provides the needed carrier mechanism (e.g., using Generic Frame Procedure, or GFP ) and bundling mechanism (e.g., PDH over VCAT and LCAS).

Yet this approach lacks sophisticated silicon components that provide scalable and cost-effective solutions for this problem. In this respect, Siverge Networks offers a family of devices to address exactly this issue (Fig. 2). The devices are available in three different price/bandwidth categories, and they’re designed to address all the Ethernet over PDH requirements:

• SV3620: 2.5-Gbit/s Ethernet over anything ( Sonet/SDH and PDH) mapper
• SV3621: 622-Mbit/s Ethernet over anything ( Sonet/SDH and PDH) mapper
• SV3622: 155-Mbit/s Ethernet over anything ( Sonet/SDH and PDH) mapper

To complete the solution, Siverge Networks also provides with these devices a comprehensive FPGA that implements all sorts of clock distribution protocols (1588, NTP) as well as CES, QoS/TM, and extensive packet editing capabilities.

This leaves us with t he last and probably the most challenging problem to solve before moving forward to Ethernet wireless backhauling— the need to interwork with deployed legacy backhauling networks and systems. Creating Ethernet islands either in the access or the core side of the network or both may well introduce various interworking and interoperability issues.

An example might be a cell site where 3G bas e stations are trying to use an Ethernet UTRAN while the RNC sits on a Sonet/SDH transport network, expecting to get a fat pipe of ATM cells. Another example might well be the same RNC and basestation, only this time the RNC sits on a Metro Ethernet cloud and gets a 1-Gigabit Ethernet interface where it needs to extract the ATM cells transmitted by its basestations over the T1s/E1s they are connected to.

One new approach that solves these interoperability and interworking problems is the Wireless U niversal G ateway concept, which is now being introduced by Si v erge Networks. The Wireless U niversal G ateway is in essence a web of interfaces and protocols in which any possible match and interworking paths are implemented (Fig. 3). Introducing this or the required subset of this functionality into the network addresses all interworking and interoperability issues that might ever exist in any wireless backhauling networks anywhere.