About the bit synchronous E1 mapping in VC-12
Michelot
First of all, for all the SDH gentlemen, merry Chrismas and happy new
year.
With the byte synchronous mode, it seems that the bit synchronous E1
mapping has been used in VC-12. Why this last kind of mapping
disappeared?
Regards,
Michhelot
Huub van Helvoort
You wrote:
> First of all, for all the SDH gentlemen, merry Chrismas and happy new
> year.
Happy Holidays to you ans all the other readers of this newsgroup.
> With the byte synchronous mode, it seems that the bit synchronous E1
> mapping has been used in VC-12. Why this last kind of mapping
> disappeared?
With bit-synchronous mapping frequency justification uses
pointer movements. This requires at least 8 bit buffering
and more complicated clock recovery (because of jitter
requirements)
With a-synchronous mapping frequency justification uses
bit stuffing with a fixed pointer. This requires at least
a 1 bit buffer and less complicated clock recovery.
Cheers, Huub.
--
reply to hhelvooort with 2 'o's
================================================================
http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...
Michelot
I wrote that yesterday and it was not visible, sorry if it is twice
> With bit-synchronous mapping frequency justification uses
> pointer movements. This requires at least 8 bit buffering
> and more complicated clock recovery (because of jitter
> requirements)
I understand that, and it's same with byte-synchronous mapping. Perhaps,
both bit- and byte-synchronous E1 mappings are complicated but, with
byte-synchronous E1 mapping (compared to bit-synchronous), you could
terminate the IT0 at the SDH source termination point, and propagated an
E1-AIS at the sink access. And perhaps it is why bit-synchronous E1 mapping
has been dropped in the past.
> With a-synchronous mapping frequency justification uses
> bit stuffing with a fixed pointer. This requires at least
> a 1 bit buffer and less complicated clock recovery.
All along the SDH transport, we have pointer movements between SDH
equipments so, at the sink termination side, clock recovery needs to treate
both justification types : VC-m bit stuffing and TU-m pointer movements,
instead only TU-m pointer as it is in synchronous mode.
What is your advice?
Regards,
Michelot
Huub van Helvoort
You wrote:
>>With bit-synchronous mapping frequency justification uses
>>pointer movements. This requires at least 8 bit buffering
>>and more complicated clock recovery (because of jitter
>>requirements)
>
> I understand that, and it's same with byte-synchronous mapping. Perhaps,
> both bit- and byte-synchronous E1 mappings are complicated but, with
> byte-synchronous E1 mapping (compared to bit-synchronous), you could
> terminate the IT0 at the SDH source termination point, and propagated an
> E1-AIS at the sink access. And perhaps it is why bit-synchronous E1 mapping
> has been dropped in the past.
That is a possibility, it was removed a long time ago, and
I don't know the reasoning for the removal.
>>With a-synchronous mapping frequency justification uses
>>bit stuffing with a fixed pointer. This requires at least
>>a 1 bit buffer and less complicated clock recovery.
>
> All along the SDH transport, we have pointer movements between SDH
> equipments so, at the sink termination side, clock recovery needs to treate
> both justification types : VC-m bit stuffing and TU-m pointer movements,
> instead only TU-m pointer as it is in synchronous mode.
In case of E12 a-synchronous mapping the TU-12 pointer justification
is not required (but the AU-4 pointer ajustment is).
In case of E12 byte-syncrounous mapping TU-12 pointer ajustment
is required but no bit stuffing.
Michelot
Thanks Huub for the time you spend to these talkings.
> In case of E12 a-synchronous mapping the TU-12 pointer justification
> is not required (but the AU-4 pointer ajustment is).
If we have a VC-4 with 63 TU-12 mapped with E12 a-synchronous, AU-4 pointer
has no reason to move. In my calculation, the bit stuffing is able to
recover E12 clock in the limit of 2.048 Mbit/s +- 2 kbit/s (around +- 1000
ppm), as we have 2 opportunity bits and 1023 data bits per 500 盜 VC-12
multiframe. It is more than the +- 50 ppm required by G.703.
Bit stuffing seems better than AU-4 pointer to take into account rate
variations, +- 1000 ppm versus +-300 ppm. But perhaps we have a problem with
the instantaneous variations.
Regards,
Michelot
Huub van Helvoort
You added:
> Thanks Huub for the time you spend to these talkings.
Always glad to help.
>>In case of E12 a-synchronous mapping the TU-12 pointer justification
>>is not required (but the AU-4 pointer ajustment is).
>
> If we have a VC-4 with 63 TU-12 mapped with E12 a-synchronous, AU-4 pointer
> has no reason to move. In my calculation, the bit stuffing is able to
> recover E12 clock in the limit of 2.048 Mbit/s +- 2 kbit/s (around +- 1000
> ppm), as we have 2 opportunity bits and 1023 data bits per 500 盜 VC-12
> multiframe. It is more than the +- 50 ppm required by G.703.
There is theoretically no reason to move. However the VC-4 will pass
several nodes with cross connects while going from ingress to egress.
These cros-connects may be implemented such that a pointer adjustment
is required to make switching VC-4 easy (e.g. align all the VC-4
before space switching).
> Bit stuffing seems better than AU-4 pointer to take into account rate
> variations, +- 1000 ppm versus +-300 ppm. But perhaps we have a problem with
> the instantaneous variations.
And timing issues, like clock recovery circuits, reference clock
selection, etc.
Michelot
> > If we have a VC-4 with 63 TU-12 mapped with E12 a-synchronous, AU-4
pointer
> > has no reason to move.
>
> There is theoretically no reason to move. However the VC-4 will pass
> several nodes with cross connects while going from ingress to egress.
> These cros-connects may be implemented such that a pointer adjustment
> is required to make switching VC-4 easy (e.g. align all the VC-4
> before space switching).
I suppose we can have also VC-12 cross-connects and, therefore, TU-12
pointer adjustments, this whatever the VC-12 mapping type.
Regards,
Michelot
Huub van Helvoort
You supposed:
Yes, in larger systems, that is possible, and that is the
reason why bit-synchronous was dropped.
Note that there are systems where the VC-4 is sent to
the tributary interface that extracts one or more of the VC12
without using a cross connect
Michelot
> > I suppose we can have also VC-12 cross-connects and, therefore, TU-12
> > pointer adjustments, this whatever the VC-12 mapping type.
>
> Yes, in larger systems, that is possible, and that is the
> reason why bit-synchronous was dropped.
Could you please write a few more words about this last sentence? I
imagine that intermediate TU-12 pointer ajustments don't cancel, don't
delete, the initial shift information between the ingress E1signal and
the SDH equipment interface clock. All successive shifts are added
relatively. Is it correct?
> Note that there are systems where the VC-4 is sent to
> the tributary interface that extracts one or more of the VC12
> without using a cross connect
Thanks for that interresting detail. And it remembers... that I'd
rather choose by myself a piece of cheese from a generous cheeseboard
than let somebody else do it for me.
Regards,
Michelot
Huub van Helvoort
You added:
>>>I suppose we can have also VC-12 cross-connects and, therefore, TU-12
>>>pointer adjustments, this whatever the VC-12 mapping type.
>>
>>Yes, in larger systems, that is possible, and that is the
>>reason why bit-synchronous was dropped.
>
> Could you please write a few more words about this last sentence? I
> imagine that intermediate TU-12 pointer ajustments don't cancel, don't
> delete, the initial shift information between the ingress E1signal and
> the SDH equipment interface clock. All successive shifts are added
> relatively. Is it correct?
Because bit-synchronous has no pointer to move, it requires
a specific cross-connect implementation. Which in this case
is very expensive because it requires a lot of buffers.
And while a-synchronous was definded and is a good, even better,
alternative, the bit-synchronous was not considered for E1, E3, E4.
(for T1 T3 it was already defined but is hardly deployed).
>>Note that there are systems where the VC-4 is sent to
>>the tributary interface that extracts one or more of the VC12
>>without using a cross connect
>
> Thanks for that interresting detail. And it remembers... that I'd
> rather choose by myself a piece of cheese from a generous cheeseboard
> than let somebody else do it for me.
Indeed, but by limiting the choice, it is easier for you to
choose and for the provider to prepare......
Michelot
> Because bit-synchronous has no pointer to move, it requires
> a specific cross-connect implementation. Which in this case
> is very expensive because it requires a lot of buffers.
Thanks that idea to put together the synchronous mappings (with stuff bits)
with VC-12 cross-connect operation.
Regards,
Michelot