- Posts: 91
- Thank you received: 0
G703 to Ethernet conversion
18 years 1 month ago #17861
by taqqi14
G703 to Ethernet conversion was created by taqqi14
hi guys!
i wana know y G703 to ethernet conversion is needed and in wht scenerios do we need this conversion and how is it done?I heard tht while converting G703 signal to ethernet , bandwidth bcomes half i.e for transporting 2Mbps G703 signal to ip , we'll b needing 4Mbps G703 sigmal cz while converting to ethernet (ip) it becomes 4/2 = 2mbps.Is this true? and y ?if its true.
If someone could explain this all "Conversion" stuff it'll b appreciated.Scenarios in which media conversions are made would be very helpfull.
thnx
rgds
Taqqi
i wana know y G703 to ethernet conversion is needed and in wht scenerios do we need this conversion and how is it done?I heard tht while converting G703 signal to ethernet , bandwidth bcomes half i.e for transporting 2Mbps G703 signal to ip , we'll b needing 4Mbps G703 sigmal cz while converting to ethernet (ip) it becomes 4/2 = 2mbps.Is this true? and y ?if its true.
If someone could explain this all "Conversion" stuff it'll b appreciated.Scenarios in which media conversions are made would be very helpfull.
thnx
rgds
Taqqi
18 years 1 month ago #17862
by Ranger24
Patience - the last reserve of the any engineer
Replied by Ranger24 on topic Re: G703 to Ethernet conversion
Hi Taqqi,
Currently the most common scenario for G703 to ethernet conversion is where traditional TDM (Time Division Multiplexing) transmission as used by voice networks is to replaced with ethernet backhaul
Traditionally voice architecture could look like this (Common to Europe):
POT --- PMUX --- SDH RING --- Local Exchange --> the world
(POT - Plain Ordinary Telephone)
(PMUX - Primary Multiplexier 30 phone calls to 1 E1 G.703)
It is desirable to change this architecture to take advantage of the growth in Metro Ethernets as Metro ethernets are cheaper to build and expand then SDH rings. So as a Telco I am looking for some way to transport my Voice traffic across ethernet rather then SDH. This is where the G.703 conversion to Ethernet is needed.
So my architecture changes to:
POT --- PMUX --- TDMoP --- Ethernet --- TDMoP --- Local Exchange
TDMoP = TDM over Packet Conversion
I add to my PMUX the capabilty to take the G.703 frame containing my voice traffic and convert it into ethernet frames. I also need a TDMoP device at the local exhange to do the reverse Ethernet to G.703 so the local exhange can handle it.
There are 2 standards / protocols that can be used:
SAToP - Structure Agnostic TDM over Packet
CESoP - Circuit Emulation Service over Packet
Ethier allows G.703 frames to be tramsitted over ethernet. CESoP is more targeted at G.703 (E1) where as SAToP is targeted at higher order TDM - E3 etc (or so I believe!).
As for the bandwidth required it is true that an E1 frame at 2mb/s requires 4mb/s for transmission over ethernet. I'll try to dig up more details this week.
br
R
Currently the most common scenario for G703 to ethernet conversion is where traditional TDM (Time Division Multiplexing) transmission as used by voice networks is to replaced with ethernet backhaul
Traditionally voice architecture could look like this (Common to Europe):
POT --- PMUX --- SDH RING --- Local Exchange --> the world
(POT - Plain Ordinary Telephone)
(PMUX - Primary Multiplexier 30 phone calls to 1 E1 G.703)
It is desirable to change this architecture to take advantage of the growth in Metro Ethernets as Metro ethernets are cheaper to build and expand then SDH rings. So as a Telco I am looking for some way to transport my Voice traffic across ethernet rather then SDH. This is where the G.703 conversion to Ethernet is needed.
So my architecture changes to:
POT --- PMUX --- TDMoP --- Ethernet --- TDMoP --- Local Exchange
TDMoP = TDM over Packet Conversion
I add to my PMUX the capabilty to take the G.703 frame containing my voice traffic and convert it into ethernet frames. I also need a TDMoP device at the local exhange to do the reverse Ethernet to G.703 so the local exhange can handle it.
There are 2 standards / protocols that can be used:
SAToP - Structure Agnostic TDM over Packet
CESoP - Circuit Emulation Service over Packet
Ethier allows G.703 frames to be tramsitted over ethernet. CESoP is more targeted at G.703 (E1) where as SAToP is targeted at higher order TDM - E3 etc (or so I believe!).
As for the bandwidth required it is true that an E1 frame at 2mb/s requires 4mb/s for transmission over ethernet. I'll try to dig up more details this week.
br
R
Patience - the last reserve of the any engineer
18 years 1 month ago #17902
by taqqi14
Replied by taqqi14 on topic Re: G703 to Ethernet conversion
thnx Ranger. and plz let me know y an E1 frame at 2mb/s requires 4mb/s for transmission over ethernet.looking fwd for it.Wud u plz explain PON (passive optical network ) and in wht scenarios its used?and whts the use or IP MUX ?can u guide me to the websites given network diagrams of everypossible network in which diff services i.e TDMoIP etc is explained with examples and how to go about it?i m into broadband services and wanto know every possible network and how it works.Since u r an expert on broadband u'll be my best resource
Rgds
Taqqi
Rgds
Taqqi
18 years 1 month ago #18125
by Ranger24
Patience - the last reserve of the any engineer
Replied by Ranger24 on topic Re: G703 to Ethernet conversion
Hi,
It is going to take me a little while to get this stuff together...but in the meantime lets tackle the bandwidth issue.
Firstly you have to understand that latancy is evil! For voice communications latancy is our enemy and we must defeat it at all costs. Now tithe circuit switching this is easy as every conversation get's it own dedicated resources and bandwidth in the form of a circuit. As soon as we introduce packet switched networks we lose this.
So we need to think carefully about how we make the best use of our new transmission i.e. ethernet.
If we consider that an E1 frame is 32 octets, and an ethernet frame can be upto 1500. Therefore we can have multiple E1 frames within the Ethernet frame.
Unfortunately the process of packetizing multiple E1 frames into a single ethernet frame causes delay.
So we have to balance the number of E1 frames per ethernet frame with the delay introduced by packetizing the frames and then consider the required bandwidth.
This is illustrated by the below table:
[code:1]
No. of E1's Per Ethernet frame Frames/Sec. Bandwidth(Mbps) Packetisation delay (ms)
2 4000 4.032 0.25
4 2000 3.040 0.5
8 1000 2.544 1
16 500 2.296 2
32 250 2.172 4[/code:1]
Typically it is acceptable for a delay of 1 ms to be present so we could get away with 8 E1 frames per ethernet frame.
More to follow. This is enough for now!
It is going to take me a little while to get this stuff together...but in the meantime lets tackle the bandwidth issue.
Firstly you have to understand that latancy is evil! For voice communications latancy is our enemy and we must defeat it at all costs. Now tithe circuit switching this is easy as every conversation get's it own dedicated resources and bandwidth in the form of a circuit. As soon as we introduce packet switched networks we lose this.
So we need to think carefully about how we make the best use of our new transmission i.e. ethernet.
If we consider that an E1 frame is 32 octets, and an ethernet frame can be upto 1500. Therefore we can have multiple E1 frames within the Ethernet frame.
Unfortunately the process of packetizing multiple E1 frames into a single ethernet frame causes delay.
So we have to balance the number of E1 frames per ethernet frame with the delay introduced by packetizing the frames and then consider the required bandwidth.
This is illustrated by the below table:
[code:1]
No. of E1's Per Ethernet frame Frames/Sec. Bandwidth(Mbps) Packetisation delay (ms)
2 4000 4.032 0.25
4 2000 3.040 0.5
8 1000 2.544 1
16 500 2.296 2
32 250 2.172 4[/code:1]
Typically it is acceptable for a delay of 1 ms to be present so we could get away with 8 E1 frames per ethernet frame.
More to follow. This is enough for now!
Patience - the last reserve of the any engineer
18 years 1 month ago #18223
by taqqi14
Replied by taqqi14 on topic Re: G703 to Ethernet conversion
hi Ranger!
I didnt understand the calculations..
Lets say we take 1 E1 conversion from G 703 to ethernet
1 E1 = 2048Kbps = 2048*1024/8 = 262144 Bytes / sec
32 bytes = 1 E1 Frame
262144 Bytes/sec = 8192Frames/sec
May b i m missing something..Can u guide me through calculations?
And how did u calculate packetization delay ?
Thnx
Rgds
Taqqi
I didnt understand the calculations..
Lets say we take 1 E1 conversion from G 703 to ethernet
1 E1 = 2048Kbps = 2048*1024/8 = 262144 Bytes / sec
32 bytes = 1 E1 Frame
262144 Bytes/sec = 8192Frames/sec
May b i m missing something..Can u guide me through calculations?
And how did u calculate packetization delay ?
Thnx
Rgds
Taqqi
18 years 4 weeks ago #18416
by Ranger24
Patience - the last reserve of the any engineer
Replied by Ranger24 on topic Re: G703 to Ethernet conversion
Hi Taqqi,
The issue here is that ethernet has ample bandwidth for 2mb/s frames so we are no restricted by the available bandwidth. We are making decisions on how best to use the bandwidth.
We are adding to the transmission process a number of new steps i.e.
- Packetisation of E1
- Depacketisation of E1
And these additional steps take time. So we need to gain time to reduce the impact of the time taken to packetise /depacketise the E1 frames.
Luckly Ehernet can transmitt the packets faster then we can generate them so we are really deciding how best to package our packets within ethernet.
If we choose the first option (2 E1 frames per ethernet packet) we minimise the delay & maximise the bandwidth required. Delay is minimised because we are only collecting 2 packets then transmiting them.
We effectively create enough time to reassemble the packets into E1 frames at the far end allowing the onward transmissin in TDM format etc.
I'll get examples of the calculations.. I haven't yet worked through them enough.
I hope this doesn't confuse matters more!
br
R
The issue here is that ethernet has ample bandwidth for 2mb/s frames so we are no restricted by the available bandwidth. We are making decisions on how best to use the bandwidth.
We are adding to the transmission process a number of new steps i.e.
- Packetisation of E1
- Depacketisation of E1
And these additional steps take time. So we need to gain time to reduce the impact of the time taken to packetise /depacketise the E1 frames.
Luckly Ehernet can transmitt the packets faster then we can generate them so we are really deciding how best to package our packets within ethernet.
If we choose the first option (2 E1 frames per ethernet packet) we minimise the delay & maximise the bandwidth required. Delay is minimised because we are only collecting 2 packets then transmiting them.
We effectively create enough time to reassemble the packets into E1 frames at the far end allowing the onward transmissin in TDM format etc.
I'll get examples of the calculations.. I haven't yet worked through them enough.
I hope this doesn't confuse matters more!
br
R
Patience - the last reserve of the any engineer
Time to create page: 0.131 seconds