Deploying Ethernet…..Technology VS Cost…..AND GFP
In the last blog I talked about the technical requirement of deploying Ethernet. Let us face it if your access devices like BTS, Node B, E-Node B come with a Ethernet interface then there is no other option but actually to have Ethernet handoff at the access. Needless to say that if the access is Ethernet then obviously the aggregation handoff or the handoff at the point of BSC or RNC would also be Ethernet.
Hemant, asked a very pertinent question as to how costly would it be to actually replace a network with Ethernet. To this there is a very cost effective solution. In the service provider domain there are two kinds of traffic at present. 70% traffic at present is the 2G or TDM interface traffic, while 30% traffic is the ehternet traffic. So how cost effective would it be to actually transform the network to a full fledged Ethernet back-haul.
Let us understand one thing, we are talking of only one carrier over here and this carrier is either the TDM SDH or it is the Ethernet. The 2G traffic is mostly static and it is not bound to increase. Also this traffic is hardcoded and follows a strict pattern. It is the Ethernet traffic which is actually growing and which can be optimized. So the call whether to completely migrate to a Ethernet back-haul will be taken/should be taken on the volume of each nature of traffic.
First of all let us understand that 80% of 2G traffic cannot be shifted overnight to a Ethernet back-haul using CES (Circuit Emulated Services). It is like destroying your house to make a cupboard appear beautiful. Hence, prima facie there needs to be a kind of technology that helps to address the problems of Ethernet carriage in the same carrier network with the same kind of boxes that are placed in the network.
Enter the need for encapsulation kind of scenario for Ethernet to ride over SDH. However, Ethernet is a asynchronous protocol and SDH is a synchronous protocol. So how do we actually make Ethernet ride over the SDH. For this very purpose there is a protocol called GFP (Generic Framing Procedure) Defined in ITU G.7041. Check the link below.
This protocol of GFP is actually the key encapsulation towards providing a proper transport mechanism of Bursty Ethernet traffic over the synchronous SDH frame.
Thus the ideal network would somewhat look like this.
In this network as we can see the essential back-bone is the SDH and there is both homing for Ethernet and the TDM on the same back-bone.
What does this do for us then?
With the coming of GFP there is now an option to take in the Ethernet Input and then finally encapsulate this and send this over the existing SDH network. This would efficiently reduce the entry cost of Ethernet in a network of a service provider which is primarily transport and would provide a very good transitional path for the network to be converted to pure Ethernet.
Network evolution, as pointed out correctly, is also a function of cost and RoI. If the present revenue is mostly from the TDM services and the rpu for the Ethernet services is lower in nature then it really makes no sense to set up a parallel overlay for the Ethernet and invest lot of resources and locking the CAPEX.
This gives a very good entry level proposition for the service provider to actually go into the Ethernet service foray and to actually start efficiently the Ethernet services.
1. Mobile back-hauls on Ethernet.
And many other services.
What my transport fraternity needs to remember?
Ø Though the network is SDH the essential services are Ethernet and they follow all the rules of Ethernet switching in a WAN environment.
Ø Each and every Data card is a different Logical Entity in the entire setup. There are many people who have this bad (VERY BAD ) habit actually to say “MY ROUTER IS CONNECTED TO THE MUX”. This is a potentially non-technical statement as routers are never connected to MUX. The router is always connected to a switching network forming a NBMA (Non Broadcast Multiple Access). Only in this case the network infrastructure is SDH.
Ø Do not treat the network of Data like to treat that of SDH. This is not a video game, but an infrastructure that provides gaming services. In SDH each service is a new trail however in Data on EoS each EoS trail is not a service but a server which can contain many services.
I will tell more about how to efficiently optimize and manage the EoS network on the lines of my last statements in the next releases of posts.
Till then, PLAN with SCIENCE, PROVISION with CARE and MAINTAIN with LOGIC……….