ETSI ETS 300 216 ed.1 (1992-12)

Network Aspects (NA); Metropolitan Area Network (MAN); Physical layer convergence procedure for 155,520 Mbit/s

DE/NA-053031

Omrežni vidiki (NA) – Velemestno omrežje (MAN) – Konvergenčni postopek na fizični plasti za hitrost 155,520 Mbit/s

General Information

• Status: Published
• Publication Date: 09-Dec-1992
• Technical Committee: NA 5 - Broadband Networks
• Current Stage: 12 - Completion
• Due Date: 04-Dec-1992
• Completion Date: 10-Dec-1992
• Ref Project: SIST ETS 300 216 E1:2003 - Network Aspects (NA); Metropolitan Area Network (MAN); Physical layer convergence procedure for 155,520 Mbit/s

Standards Content (Sample)

SLOVENSKI STANDARD
SIST ETS 300 216 E1:2003
01-december-2003
2PUHåQLYLGLNL1$±9HOHPHVWQRRPUHåMH0$1±.RQYHUJHQþQLSRVWRSHNQD
IL]LþQLSODVWL]DKLWURVW0ELWV
Network Aspects (NA); Metropolitan Area Network (MAN); Physical layer convergence
procedure for 155,520 Mbit/s
Ta slovenski standard je istoveten z: ETS 300 216 Edition 1
ICS:
35.110 Omreževanje Networking
SIST ETS 300 216 E1:2003 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST ETS 300 216 E1:2003

---------------------- Page: 2 ----------------------

SIST ETS 300 216 E1:2003
EUROPEAN ETS 300 216
TELECOMMUNICATION December 1992
STANDARD
Source: ETSI TC-NA Reference: DE/NA-053031
ICS: 33.040
Key words: Network, access, MAN
Network Aspects (NA);
Metropolitan Area Network (MAN)
Physical layer convergence procedure for
155,520 Mbit/s
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: [e-mail]
Tel.: [phone] - Fax: [phone]
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1992. All rights reserved.

---------------------- Page: 3 ----------------------

SIST ETS 300 216 E1:2003
Page 2
ETS 300 216: December 1992
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.

---------------------- Page: 4 ----------------------

SIST ETS 300 216 E1:2003
Page 3
ETS 300 216: December 1992
Contents
Foreword .5
1 Scope .7
2 Normative references.7
3 Definitions.7
4 Symbols and abbreviations .7
5 Physical Layer Convergence Procedure (PLCP) for 155,520 Mbit/s CCITT Recommendations
G.707, G.708, G.709 SDH based systems .7
5.1 Introduction .7
5.2 The PLCP frame format.8
5.3 PLCP path overhead field definitions.9
5.3.1 Path trace (J1).9
5.3.2 Bit Interleaved Parity - 8 (B3) .9
5.3.3 Signal label (C2).10
5.3.4 Path status (G1) .10
5.3.5 Multiframe indicator (H4).10
5.3.6 DQDB layer management information octets (M1, M2) .11
5.3.7 Growth octets .11
5.4 PLCP behaviour during faults .11
5.5 PLCP behaviour during DQDB layer out of service .12
5.6 PLCP operation.12
5.6.1 Receiver operation .12
5.6.1.1 Slot delineation .12
5.6.1.1.1 The H4 octet slot offset indicator
method.12
5.6.1.1.2 The header check sequence method .14
5.6.1.2 Framing state machine.15
5.6.2 Transmitter operation .17
5.6.3 Link status signal operations table .17
5.6.4 Physical layer frame timing operations table.18
History.20

---------------------- Page: 5 ----------------------

SIST ETS 300 216 E1:2003
Page 4
ETS 300 216: December 1992
Blank page

---------------------- Page: 6 ----------------------

SIST ETS 300 216 E1:2003
Page 5
ETS 300 216: December 1992
Foreword
This European Telecommunication Standard (ETS) has been prepared by the Network Aspects (NA)
Technical Committee of the European Telecommunications Standards Institute (ETSI).
This ETS details the physical layer convergence procedure for a European Metropolitan Area Network
(MAN) based on the Distributed Queue Dual Bus (DQDB) access method as defined in IEEE Standard
802.6 [6] operating at a transmission rate of 155,520 Mbit/s in accordance with CCITT Recommendations
G.707 [1], G.708 [2] and G.709 [3].

---------------------- Page: 7 ----------------------

SIST ETS 300 216 E1:2003
Page 6
ETS 300 216: December 1992
Blank page

---------------------- Page: 8 ----------------------

SIST ETS 300 216 E1:2003
Page 7
ETS 300 216: December 1992
1 Scope
This European Telecommunication Standard (ETS) defines the physical layer convergence procedure at
155,520 Mbit/s for use in the context of a subnetwork of a Metropolitan Area Network (MAN). Use of
methods defined in this ETS for other purposes is outside the scope of this ETS.
Methods of testing will be the subject of separate arrangements.
2 Normative references
This ETS incorporates, by dated or undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to, or revisions of any of these publications
apply to this ETS only when incorporated in it by amendment or revision. For undated references the latest
edition of the publication referred to applies.
[1] CCITT Recommendation G.707 (1991): "Synchronous digital hierarchy bit
rates".
[2] CCITT Recommendation G.708 (1991): "Network node interface for the
synchronous digital hierarchy".
[3] CCITT Recommendation G.709 (1991): "Synchronous multiplexing structure".
[4] CCITT Recommendation G.783 (1991): "Characteristics of synchronous digital
hierarchy (SDH) multiplexing equipment functional blocks".
[5] CCITT Recommendation I.432 (1991): "B-ISDN user-network interface -
Physical layer specification".
[6] IEEE Standard 802.6 (1990): "Distributed Queue Dual Bus (DQDB) Subnetwork
of a Metropolitan Area Network (MAN)".
3 Definitions
For the purposes of this ETS, the definitions as defined in IEEE Standard 802.6 [6] apply.
4 Symbols and abbreviations
For the purposes of this ETS, the symbols and abbreviations as defined in IEEE Standard 802.6 [6] apply.
5 Physical Layer Convergence Procedure (PLCP) for 155,520 Mbit/s CCITT
Recommendations G.707, G.708, G.709 SDH based systems
5.1 Introduction
This ETS defines a convergence procedure for transfer of Distributed Queue Dual Bus (DQDB) slots
using the Synchronous Digital Hierarchy (SDH) at a 155,520 Mbit/s physical medium rate. The rates,
formats, and other attributes of SDH are defined in CCITT Recommendations G.707 [1], G.708 [2] and
G.709 [3]. DQDB slots are mapped into VC-4 virtual containers, and the VC-4s are transported using
synchronous transport modules. A mapping of Asynchronous Transfer Mode (ATM) cells into VC-4 can be
found in CCITT Recommendation I.432 [5]. As ATM cells and DQDB slots are identical in length (53
octets) and nearly identical in format, the mapping of DQDB slots into VC-4 is identical to the ATM cell
mapping into VC-4 except for the following:
- the use of the user channel (F2) and growth (Z3) octets for carrying DQDB layer management
information octets (M1 and M2);
- the use of two bit positions in the multiframe indicator (H4) octet for providing the DQDB Link Status
Signal (LSS);

---------------------- Page: 9 ----------------------

SIST ETS 300 216 E1:2003
Page 8
ETS 300 216: December 1992
- the use of VC-4 for propagating the DQDB layer 125 μs timing along the DQDB buses;
- the optional use of either six bit positions in the multiframe indicator (H4), or the Header Check
Sequence (HCS) method for providing slot boundary indication. The HCS method for slot
delineation is identical to the Header Error Control (HEC) method for ATM cell delineation described
in CCITT Recommendation I.432 [5], section 4.5.1.1, except for the fact that the HCS is calculated
over three octets of the DQDB slot header, whereas the ATM HEC is calculated over four octets of
the ATM cell header.
CCITT Recommendations G.707 [1], G.708 [2], and G.709 [3] shall be the primary references for
providing an SDH based physical layer for DQDB with the above modifications. Descriptions of Path
OverHead (POH) field definitions in this ETS other than (M1, M2) and H4 fields are included for clarity and
completeness only.
The SDH PLCP makes use of the optional status parameter in Ph-DATA indication and Ph-DATA request
primitives (see IEEE Standard 802.6 [6], section 4.2). Hence, the status parameter is mandatory for the
service provided by the SDH PLCP.
In this ETS , the terms bus x, bus y, Ph-SAP_x, and Ph-SAP_y (x = A or B; y = B or A) will be used. Bus x
enters a DQDB node at Ph-SAP_x and exits at Ph-SAP_y whereas bus y enters a DQDB node at
Ph-SAP_y and exits at Ph-SAP_x.
5.2 The PLCP frame format
The PLCP frame format is a virtual container VC-4 that consists of 9 rows by 261 octets. The VC-4 has a
nominal duration of 125 μs. The VC-4 frame rate shall provide the 125 μs timing information. The VC-4
frames are transported between peer PLCPs by the SDH transmission system.
DQDB slots are mapped into the VC-4 as illustrated in figure 1. The VC-4 consists of one column (nine
octets) of POH plus a 9 row by 260 column payload capacity.
261 octets
J1
VC-4
B3
C2
G1
M1
9 row s
H4
M2
Z4
Z5
53 octets
DQDB slot
VC -4 Path O verH ead
Figure 1: VC-4 PLCP mapping for DQDB

---------------------- Page: 10 ----------------------

SIST ETS 300 216 E1:2003
Page 9
ETS 300 216: December 1992
The DQDB slots are located horizontally (by row) in the VC-4 payload capacity with the slot boundaries
aligned with the VC-4 octet boundaries. Because the VC-4 payload capacity (2 340 octets) is not an
integer multiple of the DQDB slot length (53 octets), a slot is allowed to cross the VC-4 boundary. Slot
boundary indication shall be provided on a 125 μs basis by use of the POH H4 octet.
48 octet slot payload
5 octet slot header
HCS
3 octets covered
by HC S
Figure 2: DQDB slot format
The slot format is illustrated in figure 2. The slot payload of 48 octets shall be scrambled before VC-4
framing. The scrambler operates for the duration of the 48 octet slot payload. Operation is suspended and
the scrambler state is retained at all other times. A self-synchronous scrambler with generator polynomial
43
x +1 shall be used. In the reverse operation, following termination of the VC-4 signal and slot delineation,
the slot payload shall be de-scrambled. The de-scrambler operates for the duration of the assumed slot
payload according to the derived slot delineation (see subclause 5.6.1.1). Operation is suspended and the
de-scrambler state is retained at all other times.
At the transmitting PLCP, an eight bit pattern shall be added (modulo 2) to the HCS field of the slot
headers. At the receiving PLCP, the same bit pattern shall be subtracted (equal to add modulo 2) from the
HCS field of the assumed slot headers. The bit pattern shall be (01010101).
5.3 PLCP path overhead field definitions
The first column of the VC-4 contains the path overhead octets. The following subclauses describe each
of the VC-4 path overhead octets and their functions. As previously noted, these descriptions are
consistent with CCITT Recommendation G.709 [3] except for the use of the user channel (F2), growth
(Z3), and multiframe indicator (H4) octets. Values of octets are described as bit patterns. The leftmost bit
of each octet is most significant.
The PLCP path is defined between two adjacent peer PLCP entities. All path overhead octets other than
M1 and M2 are related to PLCP operation and are terminated/generated at each PLCP on the
subnetwork. The M1 and M2 octets are provided for the transport of DQDB layer management information
octets and shall not be processed by the PLCP.
5.3.1 Path trace (J1)
The J1 octet is used to repetitively transmit a 64 octet, fixed length string so that a receiving PLCP can
verify its continued connection to the intended transmitter PLCP.
5.3.2 Bit Interleaved Parity - 8 (B3)
The B3 octet is allocated for the PLCP path error monitoring function. This function shall be a Bit
Interleaved Parity-8 (BIP-8) code using even parity. The PLCP path BIP-8 is calculated over all bits of the
previous VC-4. The computed BIP-8 is placed in the B3 octet of the current VC-4. The BIP-8 is calculated
after the PLCP scrambling of the slot payload.
A BIP-8 is an 8 bit code in which the first bit of the BIP-8 code calculates even parity over the first bit of
each octet in the VC-4, the second bit of the BIP-8 code calculates even parity over the second bit of each
octet in the VC-4, etc. Therefore, the BIP-8 code provides for 8 separate even parity codes covering the
corresponding bit of each octet in the VC-4.

---------------------- Page: 11 ----------------------

SIST ETS 300 216 E1:2003
Page 10
ETS 300 216: December 1992
5.3.3 Signal label (C2)
The C2 octet is allocated to indicate the construction of the VC-4 payload. The value of this octet shall be
set to code (14 hex), which indicates an IEEE Standard 802.6 [6] payload and overhead structure.
5.3.4 Path status (G1)
The G1 octet is allocated to convey the received PLCP status and performance to the transmitting PLCP.
This octet permits the status and performance of the complete duplex PLCP path to be monitored by
either PLCP entity. The coding of the G1 octet is illustrated in figure 3.
4 b its 1 bit 3 bits
FERF
FEBE
Reserved
Far End
Far End Block Error
Rec eive
Failure
Figure 3: Path status (G1) coding
The four most significant bits of the G1 octet are the Far End Block Error (FEBE) code which shall be
used to convey the count of interleaved-bit blocks that have been detected to be in error by the PLCP
BIP-8 code in the preceding VC-4. This count has nine legal values, namely zero (0000) to eight (1000)
errors. The remaining seven possible codes (1001 through 1111) shall be interpreted as zero errors.
The fifth bit is the Far End Receive Failure (FERF) signal. The FERF alerts the transmitting PLCP that a
received failure indication has been declared along the PLCP path. When an incoming failure (i.e. the
framing state machine in loss-of-frame or loss-of-slot-delineation states (see subclause 5.6.1.2) is
detected on bus x (x = A or B) that persists for 2,5 ± 0,5 seconds, a FERF shall be generated on bus y (y
= B or A) by setting the fifth bit of the G1 octet to one (1). FERF shall be detected by a one (1) in the fifth
bit of the G1 octet for ten consecutive VC-4s. When the incoming failure has ceased for 15 ± 5 seconds,
FERF shall be removed from bus y by setting the fifth bit of the G1 octet to zero (0). Removal of FERF
shall be detected by a zero (0) in the fifth bit of the G1 octet for ten consecutive VC-4s.
The remaining three least significant bits are reserved for future standardisation. The transmitting PLCP
shall encode these bits to the default code of (000). The receiver PLCP shall be capable of ignoring the
values contained in these bits.
5.3.5 Multiframe indicator (H4)
The H4 octet is the multiframe indicator for payloads. The coding of the H4 octet is illustrated in figure 4.
2 b its
6 b its
LSS
Slot O ffset Indicator
Link Status Signal
Figure 4: Multiframe indicator (H4) coding
The two most significant bits are used for the Link Status Signal (LSS) code as described in IEEE
Standard 802.6 [6], section 11.3.2. The LSS is used to communicate information about the status of the
transmission link between two adjacent PLCP entities.

---------------------- Page: 12 ----------------------

SIST ETS 300 216 E1:2003
Page 11
ETS 300 216: December 1992
The LSS codes for the H4 octet are shown in table 1.
Table 1: Link status signal codes
LSS code LSS name Link status
00 Connected Received link connected
11 rx_link_dn Received link down, no input or
forced down
01 rx_link_up Received link up
10 hob_incapable Lack of upstream head of bus
capability.
The six least significant bits of the H4 octet form the slot offset indicator. The slot offset indicator shall
contain a binary number indicating the offset in octets between the H4 octet and the first slot boundary
following the H4 octet. The valid range of the slot offset indicator value shall be 0 to 52. A received value
of 53 to 63 corresponds to an error condition.
5.3.6 DQDB layer management information octets (M1, M2)
The M1 and M2 octets carry the DQDB layer management information octets which are described in IEEE
Standard 802.6 [6], section 10.1. The DQDB layer management information octets are generated at the
head of a bus as described in IEEE Standard 802.6 [6], section 4.2, and are operated on by each DQDB
node management protocol entity as described in IEEE Standard 802.6 [6], sections 5.4.3.3, 10.2 and
10.3. There need be no correlation between TYPE = 0 or TYPE = 1 octets and the M1 or M2 octets.
5.3.7 Growth octets
The Z4 and Z5 growth octets are reserved for future standardisation. The transmitter PLCP shall encode
these octets to the default code of (00000000). The receiver PLCP shall be capable of ignoring the values
contained in these octets.
5.4 PLCP behaviour during faults
There are two types of conditions that directly influence the operation of the PLCP: DQDB layer out-of-
service, and faults introduced by the PLCP or the SDH transmission system. Faults shall force the PLCP
out-of-frame or out-of-slot-delineation (see subclause 5.6.1.2).
The out-of-frame state is entered when a loss of pointer or alarm indication signal is declared by the SDH
transmission system pointer interpretation state machine (see CCITT Recommendation G.783 [4],
Annex B). The out-of-slot-delineation state is entered when lost slot synchronism is declare
...