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.
2.
Retail.
3.
Enterprise.
4.
MSO.
5.
VPN.
6.
ILL.
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……….
Thank you sir providing great learning center(blog) for us.
ReplyDeletePlease keep posting.........
Dear Kartik, Will surely do that. I hope to give maximum that I can from the things that I have learnt all these years from my seniors and juniors. However, please post questions and queries on the same post or on the facebook link.
DeleteNice article Sir...This is like online learning of the Telecom domain for us...Telecom Domain is very small as in we dont have classes which we can attain to increase our knowledge as compared to the IT Domain where in they can learn technology from classes...Thanks Sir for these posts!!
ReplyDelete