M3 - 6.

Introduction

Introduction

Just as a multiplexing structure is defined for the plesiochronous hierarchy PDH by ITU
recommendations, so too is a multiplexing structure defined for the SDH hierarchy, also
by these recommendations. This structure defines the standard transmission rates for
synchronous signals and the way in which tributary signals from lower levels are
transported.

● SDH multiplexing
❍ Multiplexing map
❍ Containers (C-n): the transport interface
❍ Path overhead (POH)
❍ Virtual containers (VC-n): the unit of exchange
❍ Pointers and payload shift
❍ The STM-1 frame
❍ STM-N
■ Forming STM-N frames
■ Concatenation of AU-4
❍ Transporting low rate tributaries
■ Containers: C-3, C-2, C-12 and C-11
■ Virtual containers: VC-3, VC-2, VC-12 and VC-11
■ Tributary units: TU-12, TU-3 and TU-2
■ TU multiframes
■ Tributary unit groups: TUG-3 and TUG-2

http://www.trendcomms.com/multimedia/training/broa...%20networks/web/main/m3/temari/seccio6/f_arbre.htm [10/31/2007 9:17:25 PM]

M3 - 6.1. Multiplexing map

Multiplexing map

This shows the paths through which it is possible to configure an STM-1 transport frame.

On the right of the figure we can see the tributaries that can be transported. First these are mapped into their C-n
container, then an overhead is added and they become VC-n virtual containers. Next they are aligned when the
pointer bytes are associated with them, giving rise to the tributary units and administrative units, TU-n and AU-n
respectively. The multiplexing process is the next step, whereby the various units form into groups: TUG-n and AUG
(tributary unit groups and administrative unit groups, respectively). Finally these are placed in an STM-n transport
frame.

http://www.trendcomms.com/multimedia/training/bro...nd%20networks/web/main/m3/temari/seccio6/mapa.htm [10/31/2007 9:18:04 PM]

M3 - 6.2. Containers (C-n): the transport interface

Containers (C-n): the transport interface

The synchronous network was designed in such a way that it would be able to transport plesiochronous signals, as
the existing PDH networks would still be used during a transition period (indeed, synchronous and plesiochronous
networks still coexist today). Synchronous transport units were designed to transport plesiochronous signals in SDH
networks - these are called containers.

Placing the plesiochronous signals inside a container is a problem of plesiochronous multiplexing, so justification is
carried out to adapt the transmission rate of each plesiochronous signal to the rate of its associated container. For
this reason, inside a container (which is no more than a frame of bits) we can find the bits of the plesiochronous
signal together with the justification control bits and justification oppportunity bits, amongst others, depending on the
mapping procedure used, as in the case of the PDH signals themselves. As well as transporting PDH signals, the
containers can also transport ATM signals and signals from a metropolitan Ethernet network).

Let us look now at the mapping process for a 140 Mbit/s PDH tributary. On the multiplexing map we can see that the
C-4 container should be used, in which the information that arrives will be placed byte by byte.

http://www.trendcomms.com/multimedia/training/broa...tworks/web/main/m3/temari/seccio6/contenedores.htm [10/31/2007 9:18:20 PM]

M3 - 6.3. Path overhead (POH)

Path overhead (POH)

A series of bytes is added to each container (C-n) and these carry information that enables the system to manage this
container. These bytes are known as the overhead. Together, the overhead bytes and the container is known as the
virtual container. The transmission media and the network elements between the point in which a virtual container is
assembled, and the point in which it is disassembled in order to extract the information it is carrying, is called a path.
The previously mentioned overhead is therefore called a Path Overhead (POH).

This overhead provides information about the path and lets us monitor different parameters associated with the
tributary from the point in which it was introduced into the network until its plesiochronous contents are delivered.

http://www.trendcomms.com/multimedia/training/...%20networks/web/main/m3/temari/seccio6/poh.htm (1 of 2) [10/31/2007 9:18:37 PM]

M3 - 6.3. Path overhead (POH)

http://www.trendcomms.com/multimedia/training/...%20networks/web/main/m3/temari/seccio6/poh.htm (2 of 2) [10/31/2007 9:18:37 PM]

M3 - 6.4. Virtual containers (VC-n): the unit of exchange

Virtual containers (VC-n): the unit of exchange

The virtual container (VC) is the unit of transport between the input and output points for
the tributaries, whether they are plesiochronous signals, ATM signals or signals from
metropolitan Ethernet networks. A basic SDH frame has a capacity of 155 Mbit/s, which
means that it can either transport one VC-4 virtual container (designed for
plesiochronous signals at 140 Mbit/s) or three VC-3 virtual containers (designed to
transport plesiochronous signals at 34 Mbit/s or 45 Mbit/s). The payload of each of these
containers can be one high rate tributary or a combination of tributary unit groups that
contain low rate signals (see the multiplexing map).

The next step consists of placing the VC-4 inside the basic synchronous frame, the STM-
1 (synchronous transport module). This STM-1 signal is a continuous frame, like an
endless train that permanently runs back and forth between its starting point and its
destination and can fit a VC-4 exactly inside its freight cars. Here we can see the most
interesting characteristic of the SDH system: the payload can be situated between two
frames, that is, one part of the VC-4 can be in one STM-1 frame and the rest in the next
frame. In other words, the freight cars of our train are not separate: they are all
connected.

What is the reason for this? Let us continue with the train metaphor. Imagine a freight
train travelling at a constant speed of 155 km/h. The train passes under a device that
drops the containers carrying the freight (VC-4 virtual containers) into the freight cars.
These containers are dropped at a regular pace (they travel at about 150 km/h down the
dispensing pipe), and each of them fits exactly in its freight car. Let us now imagine that
there is a fluctuation in this regular pace, and the speed decreases. In this case part of
the container will fall on one freight car and part on the next.

When the train reaches its destination, the workers who are responsible for unloading
the freight cars will need to know which car each container belongs to, in order to send it
to the place on the loading bay that has been assigned for it. Fortunately, the train driver
has a list showing the freight car where each container starts (since in our system a
container can take up two freight cars, and often does so). With this information it is
possible to recover all the freight correctly.

Why do we let the payload containers be split up between different freight cars? An
alternative system could be thought up that would avoid it. By incorporating a buffering
system in the device that drops the containers into the freight cars, each container could
then be held up if needed for as long as it took for it to fit perfectly in a single freight car.
A container held up in this way would then wait for the first freight car into which it would
fit completely. The disadvantage of this system is that, if the delays were to build up, the
system would need an arbitrarily large buffering capacity, and in addition the delays in
the delivery of the freight at its destination could also get to be arbitrarily long.

http://www.trendcomms.com/multimedia/training/b...networks/web/main/m3/temari/seccio6/virtual.htm (1 of 3) [10/31/2007 9:18:52 PM]

M3 - 6.4. Virtual containers (VC-n): the unit of exchange

To get back to SDH transmission, the above solution would lead to unacceptable delays,
as well as arbritarily large buffers (temporary storage subsystem). That is why the first
solution was adopted. Each STM-1 frame (freight car) receives one VC-4 virtual
container that can be split into two consecutive frames. The starting point of each VC-4
container inside the STM-1 frame is indicated by the value of AU-4 pointer bytes in the
frame overhead, which increase or decrease their value depending on the bit rate of the
VC-4 container. The nominal rate of a VC-4 virtual container is 149.76 Mbit/s.

At this point a paradox arises: if the SDH system is based on the synchronization of the
signals, why do fluctuations occur in the bit rates of the virtual containers? The answer
lies in the practical limitations of the above mentioned synchronization. SDH networks
use a high quality clock for synchronizing the network elements that they are made up
of. However, bear in mind that:

● A number of SDH islands exist (for instance, the SDH networks in each country,
or even of every operator), each with its own synchronization source - which,
although they may be nominally the same, are in fact almost never exactly the
same.
● Inside a single SDH network, different types of breakdown may cause a
temporary loss of synchronization, in which case every network element switches
over to a secondary clock source, which may be its internal clock, of a lesser
quality than the one provided by the primary source, and as a result this may lead
to frequency offsets (bit rate).

http://www.trendcomms.com/multimedia/training/b...networks/web/main/m3/temari/seccio6/virtual.htm (2 of 3) [10/31/2007 9:18:52 PM]

M3 - 6.4. Virtual containers (VC-n): the unit of exchange

http://www.trendcomms.com/multimedia/training/b...networks/web/main/m3/temari/seccio6/virtual.htm (3 of 3) [10/31/2007 9:18:52 PM]

M3 - 6.5. Pointers and payload shift

Pointers and payload shift

Let us look more closely at the problem of differences in frequency between the tributary and the
carrier frame (synchronous transport module). We must accept the fact that the networks are not
synchronized, which makes it inevitable that there will be tiny differences of millionths between
the nominal values and the real values of the bit rates being looked at, which will build up over
time.

What happens when the bit rate of the VC-4 is too slow compared to that of the STM-1 signal?
The pointer of the corresponding AU-4 will have to update its value, pointing to a later start
position. In order to keep the VC-4 containers contiguous, positive justification is used, that is,
stuffing bytes are added. The figure shows how a unitary increment in the pointer value means a
shift of three bytes.

What if the rate of the VC-4 is too fast compared to that of the STM-1 signal? In this case a point
will be reached where the payload will have to be moved forward to provide extra space for three
bytes (known as H3) given up by the AU-4 pointer.

The pointers are placed in set positions inside the carrier frame. The AU pointer (administrative
unit) is located directly in the STM-1 frame, while the tributary units (TU) have other pointers that
occupy set positions inside the VC-4. To locate a VC-n, first locate the VC-4 and then the TU-n
pointer.

Without a doubt, this is the key mechanism in SDH networks: synchronous frames, the STM-1
modules, that transport payloads that may not be synchronized. The pointer mechanism does
have a downside, however: a pointer adjustment causes a slip several bits long (for instance, an
AU pointer adjustment causes a slip of 24 bits). This slip is unimportant as long as the signal
remains inside the SDH network, but when the tributary is extracted from the SDH signal that is
transporting it, the phase slip causes phase fluctuation peaks that are difficult for the PDH
networks to deal with.

http://www.trendcomms.com/multimedia/training/b...networks/web/main/m3/temari/seccio6/puntero.htm (1 of 2) [10/31/2007 9:19:13 PM]

M3 - 6.5. Pointers and payload shift

http://www.trendcomms.com/multimedia/training/b...networks/web/main/m3/temari/seccio6/puntero.htm (2 of 2) [10/31/2007 9:19:13 PM]

M3 - 6.6. The STM-1 frame

The STM-1 frame

Finally we come to the basic STM-1 carrier frame, which consists of two overheads, one
pointer and a space for the payload. The overheads are the regeneration section
overhead (RSOH), associated with the regenerators, and the multiplex section overhead
(MSOH), associated with the multiplexers. The space for the payload carries the VC-4
container, the first byte of which is signalled by the AU-4 pointer and which is allowed to
move in order to accommodate frequency variations. In previous sections we have
looked at an example in which a 140 Mbit/s signal was mapped into a VC-4, but the
multiplexing map lets the STM-1 signal transport other types of plesiochronous signals
and even combinations of signals. All the possibilities are shown in the table below:

Composition 2 Mbit/s 34 Mbit/s 140 Mbit/s

1xVC-4 0 0 1
3xVC-3 0 3 0
21xVC-12+2xVC-3 21 2 0
42xVC-12+2xVC-3 42 1 0
63xVC-12 42 1 0

Table 1.- Composition of an STM-1 signal: possibilities

The basic transport rate is 155.52 Mbit/s and is defined in the ITU-T recommendation
G.707. The basic STM-1 frame is represented, for the sake of simplicity, as a rectangular
structure of 270 columns and 9 rows, which gives a total of 270 x 9 = 2430 bytes. The
frame period is therefore:

(2430 byte x 8 bit/byte)/155.52·106bit/s = 125ms.

As mentioned above, the overhead of an STM-1 signal (SOH) is divided into two parts:
the MSOH and the RSOH. The overheads contain information from the system itself,
which is used for a wide range of management functions, such as monitoring
transmission quality, detecting failures, managing alarms, data communication channels,
service channels, etc. These functions will be described in more detail in the section on
network management services.

The VC is pointed at by the AU pointer; for the case of an VC-4, the virtual container and
the pointer together are referred to as level 4 administrative unit, or AU-4 for short.

http://www.trendcomms.com/multimedia/training/...20networks/web/main/m3/temari/seccio6/stm1.htm (1 of 2) [10/31/2007 9:19:26 PM]

M3 - 6.6. The STM-1 frame

http://www.trendcomms.com/multimedia/training/...20networks/web/main/m3/temari/seccio6/stm1.htm (2 of 2) [10/31/2007 9:19:26 PM]

M3 - 6.7. STM-N

STM-N

By multiplexing basic STM-1 frames, STM-N higher order frames can be formed. This
section looks at the options for doing so in more detail (direct or indirect multiplexing),
along with the concept of concatenation.

http://www.trendcomms.com/multimedia/training/bro...nd%20networks/web/main/m3/temari/seccio6/stmn.htm [10/31/2007 9:19:40 PM]

M3 - 6.7.1. Forming STM-N frames

Forming STM-N frames

The basic frame in the SDH hierarchy is the sychronous transport module STM-1. The hierarchy defines higher order frames
whose bit rates are obtained by multiplying successively by four. For the sake of simplicity, each of the bit rates is usually
referred to by its rounded-off value, as shown in the table:

Frame Bit rate (kbits/s) Rounded-off bit rate

STM-1 155.520 155 Mbit/s
STM-4 155.520 x 4 = 622.080 622 Mbit/s
STM-16 155.520 x 16 = 2.488.320 2.5 Gbit/s
STM-64 155.520 x 64 = 9.953.280 10 Gbit/s

Table 2.- SDH sychronous transport modules

To form an STM-N synchronous transport module from an STM-1, AU-4 byte-interleaved multiplexing is used, adding a new
overhead; this is because the multiplexers take apart the section overheads received and add new overheads to the
multiplex signals they transmit.

Like the STM-1 frame, the STM-N frame is represented as a rectangular structure of 270 x N columns and 9 rows, which
gives a total of 270 x N x 9 = 2430 x N bytes. Nonetheless, the frame period remains the same as that of the STM-1 frame:
125ms. The new section overhead is therefore 9 x N columns and 8 rows (one row is taken up by the AU-N pointer, which
has been formed by interleaving the bytes).

When looking at the STM-N frames, the concept of indirect multiplexing must be introduced. To explain this, let us look at
the example of the STM-16 frame. Forming one of these frames by direct multiplexing means that it has been formed by
interleaving bytes from 16 STM-1 frames. But an STM-16 structure can also be obtained from 4 STM-4 frame, that is, by
indirect multiplexing (not directly from STM-1 frames). In this case, the interleaving is carried out in blocks of 4 bytes. The
end result is therefore the same as that achieved by interleaving bytes from STM-1.

In addition to its functions outlined in previous sections, the pointers mechanism also facilitates the construction of STM-N.
In effect, due to the imperfection that is inherent to the synchronization of networks, the STM frames reach the multiplexers
with random relative alignments, that is, some of them out of phase with respect to the others. Nonetheless, the STM-N
higher order frame that leaves the multiplexer keeps its bytes grouped together in a single block. The payloads of the frames

http://www.trendcomms.com/multimedia/training/b...tworks/web/main/m3/temari/seccio6/formacion.htm (1 of 2) [10/31/2007 9:20:10 PM]

M3 - 6.7.1. Forming STM-N frames

to the multiplexed can be interleaved without needing prior alignment, since the virtual containers will have a pointer value
that has been recalculated in the overhead of the outgoing frame.

http://www.trendcomms.com/multimedia/training/b...tworks/web/main/m3/temari/seccio6/formacion.htm (2 of 2) [10/31/2007 9:20:10 PM]

M3 - 6.7.2. Concatenation of AU-4

Concatenation of AU-4

Supposing we want to transmit a broadband signal of hundreds of Mbit/s inside an SDH

signal. The SDH system does not define optimized containers for transporting tributary
signals whose bit rate is higher than 140 Mbit/s. This means that a signal with a
transmission rate of higher than 140 Mbit/s cannot be packed in any predefined
container. So, how can we transport such a signal?

The concatenation mechanism provides a solution to this problem. It consists of

combining the number of virtual containers needed to form a virtual container whose
capacity is greater than or equal to the capacity required.

ITU recommendations define the concatenation of VC-2 and VC-4 virtual containers. For
a signal of hundreds of Mbit/s it is best to associate the structures with the largest
capacity available, that is, the VC-4, capable of accomodating signals of up to 140 Mbit/
s. Additionally, the STM-4 structure provides a rate of 622 Mbit/s. The process consists
of forming a container based on several concatenated VC-4 that takes up the whole
STM-4 frame. Note that the structure is analogous to that of an STM-1 in relation to its
VC-4: The STM-4 frame transports a single virtual container, instead of transporting 4
byte-interleaved VC-4 from other STM-1 frames. Concatenation guarantees the integrity
of a sequence of bits in the broadband signal transported.

The STM-4c frame (STM-4 with concatenation) has a space of 1040 columns for the
payload. Since it is a virtual container, called VC-4-4c (the last 4 due to the fact that four
VC-4 are concatenated), one column is reserved for the path overhead (POH) and 3
columns are for fixed stuffing, leaving 1040 columns for the C-4-4c container. It can
easily be seen that this container has a capacity of 599.040 Mbit/s, enough to transport
standard broadband signals (for the sake of simplicity, in this case we talk about 600
Mbit/s broadband signals, rounding up the bit rate). The VC-4-4c container is
standardized for transporting ATM and other broadband signals. ITU-T usually considers
pointers too, so we talk about AU-4-Xc transported over STM-N. The value of X is only
limited by the maximum payload capacity of the STM-N used. In the previous example
X=4 and N=4. Other possible values for X=4 are N=16 and N=64, although for the
moment this is more theoretical than of any practical application.

The AU-4-4c pointer is formed by interleaving the bytes of the pointers of the
concatenated AU-4. Before interleaving, the first AU-4 takes the typical values of any
conventional AU-4 pointer, while the remaining AU-4 pointers take fixed values in their
first bits, to indicate concatenation.

VC-4-4c can be transported in STM-16 and STM-64 frames too.

http://www.trendcomms.com/multimedia/training/broad...tworks/web/main/m3/temari/seccio6/concatenacion.htm [10/31/2007 9:20:32 PM]

M3 - 6.8. Transporting low rate tributaries

Transporting low rate tributaries

The transport of plesiochronous signals from hierarchical levels under 140 Mbit/s in SDH
networks defines a series of synchronous signals that make up the elements of the
multiplexing map previously introduced. This section presents these elements and their
composition.

http://www.trendcomms.com/multimedia/training/broadband%20networks/web/main/m3/temari/seccio6/baja.htm [10/31/2007 9:21:11 PM]

M3 - 6.8.1 Containers: C-3, C-2, C-12 and C-11

Containers: C-3, C-2, C-12 and C-11

So far we have looked at the transport of tributaries in STM frames in the VC-4 container, which defines a higher order
path. However, it is more common to use tributaries at lower rates that define lower order paths. Other containers exist
for these, defined in such a way as to optimize their transport: C11, C12, C2 and C3 (see also the multiplexing map):

Container Carries signals at

C-11 1.544 Mbit/s
C-12 2.048 Mbit/s
C-2 6.312 Mbit/s
C-3 34.368 Mbit/s and 44.736 Mbit/s
C-4 139.264 Mbit/s

The containers contain the bits of the tributary signal and other justification opportunity and justification control bits or
additional information (for C-11 and C-12).

http://www.trendcomms.com/multimedia/training/broa...rks/web/main/m3/temari/seccio6/masContenedores.htm [10/31/2007 9:21:42 PM]

M3 - 6.8.2. Virtual containers: VC-3, VC-2, VC-12 and VC-11

Virtual containers: VC-3, VC-2, VC-12 and VC-11

Virtual containers are formed when the corresponding path overhead (POH) is added to the C-n containers. The
virtual containers VC-11 and VC-2 are the result of mapping in the American plesiochronous hierarchy, but here we
will limit ourselves to describing the virtual containers for European PDH signals.

For 34 Mbit/s signals mapped into VC-3 containers, from the multiplexing map it can be seen that the VC3 can be
transported inside a VC-4 or can be multiplexed in threes directly over the STM-1 frame. This second case defines a
multiplexing route that permits compatability with interfaces from the North American hierarchy STM-0 (51 Mbit/s) via
an AU-3 administrative unit.

In the first case a VC-4 virtual container transports three VC-3. There are three TU-3 pointers that locate the VC-3
with respect to the TU-3, pointing at the J1 byte, the first of the POH of a VC-3.

In the case of VC-3 via AU-3 there are three AU-3 pointers in the STM-N frame that indicate the beginning of the
respective virtual containers. The pointer bytes appear interleaved in the space assigned for them in the structure of
the synchronous transport module.

The VC-12 (and likewise the VC-2 and the VC-11) must be transported in other containers with a greater capacity
(VC-3 or VC-4) before being introduced in the STM-1 frame. The containers with a greater capacity, which in the
case of European countries will be of the type VC-4, can transport up to 63 VC-12 in the STM-1 frame (see the table
showing the possible composition of an STM-1 frame). The VC-4 container has 63 pointers that find the location of
each of the VC-12 transported with respect to the VC-4. Each of these pointers signals the start byte of the
respective path overheads (POH), the V5 byte, which is the first in the sequence. Together, each pointer and its VC-
12 virtual container is called a tributary unit (TU-12), so the pointers are known as TU pointers.

http://www.trendcomms.com/multimedia/training/broad...0networks/web/main/m3/temari/seccio6/masVirtual.htm [10/31/2007 9:22:10 PM]

M3 - 6.8.3. Tributary Units TU-12, TU-3 and TU-2

Tributary Units TU-12, TU-3 and TU-2

So that the VCs can really float through the network, a pointer is needed that signals the
start of the POH, as has been mentioned in previous sections. Together, the pointer and
the VC-n make up the tributary unit (TU). The process of adding the pointer is known as
alignment. The TU-3 corresponds to the VC-3, the TU-2 corresponds to the VC-2 and
the TU-12 corresponds to the VC-12 and also the VC-11.

http://www.trendcomms.com/multimedia/training/broa...20networks/web/main/m3/temari/seccio6/unidades.htm [10/31/2007 9:22:31 PM]

M3 - 6.8.4. TU multiframes

TU multiframes

The processes of mapping in virtual containers associated with lower order paths define
what are known as TU multiframes. The lower order paths are VC-11, VC-12, VC-2 and
VC-3 paths. The higher order paths are VC-4 and also VC-3, which is thought of as a
higher order path if it follows a multiplexing path via AU-3 (see the multiplexing map). For
VC-11 and VC-12 containers, multiframes are only defined in floating mode.

In the case of 2 Mbit/s signals, the multiframe is formed by associating four of these
signals and their corresponding TU-12. Each of these TU-12 travels in the VC-4 of a
different STM-N frame. There exists a multiframe overhead formed by the first bytes of
the TU-12: 4 bytes in total. The first two bytes make up the pointer of the VC-12, that is,
they signal where the multiframe payload begins. Inside the VC-4 path overhead, there
is a multiframe indication byte (called H4) that indicates the number of TU in the
multiframe that contains the following STM-N signal.

http://www.trendcomms.com/multimedia/training/broad...networks/web/main/m3/temari/seccio6/multitramas.htm [10/31/2007 9:22:57 PM]

M3 - 6.8.5. Tributary unit groups: TUG-2 and TUG-3

Tributary unit groups: TUG-2 and TUG-3

The multiplexing map shows how an AU-4 container can be formed from a VC-4 that contains
a C-4 or three TUG-3 multiplexed by byte interleaving, that is, three groups of level three
tributary units.

A tributary unit group (TUG) is an SDH signal made up from the byte-interleaved multiplexing
of tributary units (TU). In other cases lower order TUG are multiplexed to form higher order
TUG (for instance, seven multiplexed TUG-2 form one TUG-3), and in other cases a TUG is
formed from a single tributary unit (for instance, a single TU-3 is enough to form a TUG-3).

An example may be useful to illustrate this multiplexing. Let us consider a VC-4 made up of
three TUG-3. Let us now consider one of these TUG-3. Imagine we wanted to introduce a
mixed payload in this TUG-3 consisting of nine TU-12 and four TU-2. The nine TU-12 can be
mutiplexed in threes and can take up three TUG-2. The four TU-2 will take up four TUG-2. In
total there are seven TUG-2 that can be multiplexed to form a TUG-3.

http://www.trendcomms.com/multimedia/training/b...0networks/web/main/m3/temari/seccio6/grupos.htm (1 of 2) [10/31/2007 9:23:17 PM]

M3 - 6.8.5. Tributary unit groups: TUG-2 and TUG-3

http://www.trendcomms.com/multimedia/training/b...0networks/web/main/m3/temari/seccio6/grupos.htm (2 of 2) [10/31/2007 9:23:17 PM]