PDH transport over OTN

[Michelot]

Bonjour Huub,

If we have around 1000 x E1 to transport asynchronously over OTN, is
there another solution than to use STM-16?

I just see E1 in VC-12, in VC-4, in STM-16, in OPU1.

Best regards,
Michelot

[Huub van Helvoort]

Bonjour Michelot,

You wrote:

> If we have around 1000 x E1 to transport asynchronously over OTN, is
> there another solution than to use STM-16?
>
> I just see E1 in VC-12, in VC-4, in STM-16, in OPU1.

That will be an efficient way to do it.

Another way is to multiplex 64 E1 into E4 and map the
E4 into VC-4 into STM-16. This is a little more efficient, because
in this way there are 64 E1 in a VC-4 instead of 63.

The smallest container in the OTN is the ODU0 with 1.25 Gbit/s,
transporting a single E1 per ODU0 is very inefficient,
Even transporting an E4 per ODU0 is inefficient.

Cheers, Huub.

--
reply to hhelvooort with 2 'o's
================================================================
http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

[Michelot]

Bonjour Huub,

> Another way is to multiplex 64 E1 into E4 and map the
> E4 into VC-4 into STM-16. This is a little more efficient, because
> in this way there are 64 E1 in a VC-4 instead of 63.

Thanks for remainding me it.

> transporting a single E1 per ODU0 is very inefficient,
> Even transporting an E4 per ODU0 is inefficient.

You're right, we don't have to mix up the tributary signals with a
kind of PDH multiplexing that doesn't exist in OTN.

> The smallest container in the OTN is the ODU0 with 1.25 Gbit/s,

Is it still the case (since the amendment 3)?
With the ODUflex, I'm a little bit confused.

Best regards,
Michelot

[Bert Klaps]

On Mar 3, 3:30 pm, Michelot <mhostett...@voila.fr> wrote:
> > The smallest container in the OTN is the ODU0 with 1.25 Gbit/s,
>
> Is it still the case (since the amendment 3)?
> With the ODUflex, I'm a little bit confused.

Hi Michelot,

ODUflex has two applications:

1. mapping of CBR clients into OTN: only for client signals above
2.488 Gbps
Below that, you'd use an ODU1 or ODU0.

2. GFP-F mapped packets: basically any rate could be configured
though it doesn't make much sense to choose something else
than Nx 1.25 Gbps time slots. In the network the ODUflex will
occupy an integer number of time slots anyway.

Regards,
Bert Klaps

[Michelot]

Bonsoir Bert,

Very glad to read you. Thanks for your time and for the summary about
this subject.

> 2. GFP-F mapped packets: basically any rate could be configured...

It was actually this point that had intrigued me.

>     ...though it doesn't make much sense to choose something else
>     than Nx 1.25 Gbps time slots...

Thanks for your opinion, we can go on with that description.

Best regards,
Michelot

[che...@gmail.com]

Dears, Does anyone heard about Mapping E1 into ODU Epsilon?, i couldn't find any thing about ODU Epsilon on the internet, does anyone know about it?

[Huub van Helvoort]

Hello Chesiix,

You ask:

> Dears, Does anyone heard about Mapping E1 into ODU Epsilon? > i couldn't find any thing about ODU Epsilon on the internet,

> does anyone know about it?

ODU Epsilon is not a standard term.
It may be a commercial name.

BTW: Mapping an E1 (2 Mb/s) into the smallest ODU (ODU0 = 1.25 Gb/s)
is a waste of bandwidth.

Regards, Huub.

[che...@gmail.com]

Dear Huub,

Thanks for your reply,
Currently in our country, customers have lots of E1 traffic which needs to be transferred trough their new OTN network and the only solution is using new SDH equipment to aggregate those into STM-n. meaning adding a technology which is almost phased out.

That's why we are looking for such features like ODUe so we can directly map E1s into ODU0 instead of using SDH.

By the way you're totally right and Mapping and even using E1 traffic nowadays makes no sense.