Subject: RE: TDM types and their implications

From: "Bob Barrett" <[email-masked]>
Date: Wed, 18 Sep 2002 15:07:27 +0100

Yaakov

Couple points:

#1 There are superframe specs other than CAS that need to be taken into
account. Minimum for structured is two frames, as there are odd and even
frame TS0 formats. This applies to your 'B' and 'C' cases.

#2 I like case 'B' as the default, with the number of bytes per packet equal
to one or two TDM frames.

In the unstructured case 'A' the implementation simply chooses an arbitary
point to start the bit count, and counts 'n' TDM frames worth of bits for
the packetiser. Note that the implementation needs to turn off the frame
recognition function at the ingress when operating in clear channel as BERT
patterns can spoof framing and really mess things up.

In the structured cases ('B', 'C' and 'D') the boundary is the first bit of
TS0, identified by the ingress framer.

In both cases the entire 'frames-worth' of bits, including the received TS0,
is encoded by the packetiser and played out at the egress. This ensures that
any bits set in TS0 are faithfully reproduced at the egress without recourse
to any special signalling mechanism to send the contents of TS0 alarm,
National and International bits to the far end. The egress clock recovery
and play out mechanism is the same for clear channel and any of the
structured services.

It is logical to set up the egress de-packetiser / clock recovery buffer to
be based on an integral number of superframes to match the superframe
specification on the ingress service. This ensures that there is a full
superframe in the buffer that can be used to spoof the superframe in the
case of bulk packet loss due to a PSN restoration event.

Random packet loss is dealt with by playing out a subsitute frame (or
frames) from a previously received packet, which, if the implementation of
the buffer management is smart, will be in the buffer from a previous
packet, waiting to be overwritten by the data from the packet that was lost.
In the case of CAS and RBS it repeats the eight bits in TS16 from a previous
frame, and also the encoded voice / data bits from the previous frame.

At least that's the theory for spoofing CAS in a simple implementation i.e.
an implementation that does not extract CAS and implement a resilient CAS
spoofing system. This simple implementation idea needs to be tested for the
boundary cases to ensure that the end systems don't get into a fatal embrace
situation due to (simple) CAS spoofing and the distributed state machines of
CAS. I haven't had the time to do that yet, and I would welcome help with
that process from any CAS expert that is listening.

Thanks

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Yaakov
Stein
Sent: 17 September 2002 08:55
To: [email-masked]
Subject: [PWE3] TDM types and their implications

Sasha, Shahram, Tim, Tom, Andy, Bob, etc.
I would like to suggest a possible division of the TDM space,
on the basis of which reasonable recommendations
regarding the non-SONET case can be made.
In the past, e.g. the riegel-requirements draft,
the break-down of TDM types has not been completely satisfactory,
so I would like to propose the following classification.
The list represents an "inclusion" relationship,
with each item being a superset of the following ones.
A) (simple) bit stream
B) framed TDM
C) channelized (AKA structured) TDM
D) structured with CAS
Explanations:
A) A (simple) bit stream is a serial signal conforming to G.702/G.703.
For example a T1 is considered a raw 1.544 Mbps bit stream,
with no special meaning to the framing bit.
There is thus no meaning to bit alignment in bytes or in frames.
This is the only meaningful characterization for "unframed" lead-line
services,
but any TDM stream, even a completely structured one,
could be considered a bit stream of this type.
B) A framed TDM stream is one which has synchronization
(e.g. the framing bit of the T1 and timeslot 0 of an E1)
as described in G.704 sections 1 and 2,
but not necessarily any other structure.
A framed T1 has only 24*8*8Kbps = 1.536 Mbps
and a framed E1 has only 31*8*8Kbps = 1.984 Mbps
available for data.
For framed TDM there is meaning to bit alignment in bytes
and byte alignment in frames.
C) A channelized/structured TDM stream
is framed AND has defined 8-bit channels,
as defined in G.704 sections 3-6.
When there are voice channels this is the natural representation,
although for PW transport even voice-carrying TDM
could be considered to be a framed TDM stream
or even a simple bit stream.
D) The most complex structure is called "structured with CAS"
in the ATM literature. It is similar to channelized/structured, but
in addition to the frame structure there is multiframe
(or superframe) structure as well.

With these definitions in hand,
we can now try to map the various TDM types to PW transport mechanisms.
My suggestion is to ensure robustness by requiring a transport method
that matches the most specific level of the particular TDM stream,
but to allow more general methods.
Hence, for A) general bit stream, we can do no better than to
chop the bit stream into segments of an arbitrary (but constant) number of
bytes
and encapsulate these. No bit alignment or frame integrity is needed,
but the packets MUST contain a constant number of bits
for timing recovery in the presence of packet loss.
The number of bytes per packet may be required to match
the capabilities of end-use equipment, e.g. 32, 47, 783, etc.
We will call this method BIToPSN from here on.
Although it has been suggested several times
there is as yet no I.D. officially proposing it.
For B) framed bit streams, one MUST be able to chop the bit stream
into segments of integral multiples of frames,
and maintain frame integrity. This is CESoPSN.
Of course, one MAY use BIToPSN,
but one loses the ability to distinguish frame-start,
which is useful in this context.
For C) channelized (structured ) TDM, there are two methods
based on whether the timeslots are dynamically allocated.
The TDMoIP draft supports both and MUST be available for this case.
Of course one MAY use CESoPSN or even BIToPSN,
but one loses the ability to quickly extract individual timeslots,
which is useful during packet loss, or if other NSP functions
are required (e.g. monitoring of in-band signaling).
If CESoPSN is used for T1 one SHOULD use
initial-padding rather than T1-in-E1 according to G.802
(unless interfacing with G.802-compliant equipment).
One exception to the above statement is framed T3/E3 signals.
These, although having structure,
SHOULD always be handled using CESoPSN.
This is because in PDH signals
the incorporated channels have different clocks,
the handling of which is beyond the scope of PWE.
Finally, for "structured with CAS" TDMoIP MUST be available,
but CESoPSN MAY be used - in which case one SHOULD
use the entire multiframe as the packet length
(unless the latency is intolerable).
Of course, BIToPSN MAY be used as well.
Any comments?
Y(J)S
Yaakov (Jonathan) Stein        [email-masked]
Chief Scientist                        +972 3 6455389   +972 2 5889159
RAD Data Communications   24 Raoul Wallenburg St., Tel-Aviv 69719, Israel
Have you read my book yet ? <http://www.dspcsp.com/>
<http://www.amazon.com/exec/obidos/ASIN/0471295469/>

---

From: Max Riegel <[email-masked]>
Date: Fri, 20 Sep 2002 14:05:58 +0200

>frame, and also the encoded voice / data bits from the previous frame.

In the case of having CCS bits in TS16 it might be better not to repeat the 
bits of the previous frame but to send 0xFF in TS16 to indicate that there 
has been a transmission error and force a retransmission of the signaling 
frame. Some implementations might behave better when there is a clear 
indication that a transmission error has occurred.

Bye
Max

-- 
_____________________________________________________
Maximilian Riegel, <[email-masked]>
ICM N Advanced Standards & Fora; Ph: +49 89 722 49557