Network Aspects (NA); Metropolitan Area Network (MAN); Physical Layer Convergence Procedure (PLCP) for 622,080 Mbit/s CCITT Recommendations G.707, G.708 and G.709 SDH based systems

DE/NA-053033

Omrežni vidiki (NA) – Velemestno omrežje (MAN) – Konvergenčni postopek na fizični plasti (PLCP) za hitrost 622,080 Mbit/s – Priporočila CCITT G.707, G.708 in G.709 – Na SDH temelječi sistemi

General Information

Status
Published
Publication Date
28-Mar-1994
Technical Committee
Current Stage
12 - Completion
Due Date
04-Apr-1994
Completion Date
29-Mar-1994

Buy Standard

Standard
ETS 300 276 E1:2003
English language
20 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)

SLOVENSKI STANDARD
SIST ETS 300 276 E1:2003
01-december-2003
2PUHåQLYLGLNL 1$ ±9HOHPHVWQRRPUHåMH 0$1 ±.RQYHUJHQþQLSRVWRSHNQD
IL]LþQLSODVWL 3/&3 ]DKLWURVW0ELWV±3ULSRURþLOD&&,77**LQ
*±1D6'+WHPHOMHþLVLVWHPL
Network Aspects (NA); Metropolitan Area Network (MAN); Physical Layer Convergence
Procedure (PLCP) for 622,080 Mbit/s CCITT Recommendations G.707, G.708 and
G.709 SDH based systems
Ta slovenski standard je istoveten z: ETS 300 276 Edition 1
ICS:
35.110 Omreževanje Networking
SIST ETS 300 276 E1:2003 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

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

SIST ETS 300 276 E1:2003

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

SIST ETS 300 276 E1:2003
EUROPEAN ETS 300 276
TELECOMMUNICATION March 1994
STANDARD
Source: ETSI TC-NA Reference: DE/NA-053033
ICS: 33.080
MAN
Key words:
Network Aspects (NA);
Metropolitan Area Network (MAN)
Physical Layer Convergence Procedure (PLCP) for 622,080 Mbit/s
CCITT Recommendations G.707, G.708 and G.709
SDH based systems
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
F-06921 Sophia Antipolis CEDEX - FRANCE
Postal address:
650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
Office address:
c=fr, a=atlas, p=etsi, s=secretariat - secretariat@etsi.fr
X.400: Internet:
Tel.: +33 92 94 42 00 - Fax: +33 93 65 47 16
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 1994. All rights reserved.
New presentation - see History box

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

SIST ETS 300 276 E1:2003
Page 2
ETS 300 276: March 1994
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 276 E1:2003
Page 3
ETS 300 276: March 1994
Contents
Foreword .5
1 Scope .7
2 Normative references.7
3 Definitions.7
4 Symbols and abbreviations .7
5 Physical layer convergence procedure for 622,080 Mbit/s CCITT Recommendations G.707,
G.708 and G.709 SDH based systems .8
5.1 Introduction .8
5.2 The PLCP frame format.8
5.3 PLCP path overhead field definitions.10
5.3.1 Path trace (J1).10
5.3.2 Bit interleaved parity - 8 (B3).10
5.3.3 Signal label (C2).10
5.3.4 Path status (G1) .10
5.3.5 Multiframe indicator (H4).11
5.3.6 DQDB layer management information octets (M1 - M2).11
5.3.7 Growth octets .11
5.4 PLCP behaviour during faults .12
5.5 PLCP behaviour during DQDB layer out of service .12
5.6 PLCP operation.13
5.6.1 Receiver operation .13
5.6.1.1 Slot delineation using the header check sequence
method.13
5.6.1.2 Framing state machine.14
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 276 E1:2003
Page 4
ETS 300 276: March 1994
Blank page

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

SIST ETS 300 276 E1:2003
Page 5
ETS 300 276: March 1994
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 622,080 Mbit/s in accordance with CCITT Recommendations
G.707 [1], G.708 [2] and G.709 [3].

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

SIST ETS 300 276 E1:2003
Page 6
ETS 300 276: March 1994
Blank page

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

SIST ETS 300 276 E1:2003
Page 7
ETS 300 276: March 1994
1 Scope
This European Telecommunication Standard (ETS) defines the physical layer convergence procedure at
622,080 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 below.
For dated references, subsequent amendments to or revisions 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)".
[7] ETS 300 147: "Transmission and multiplexing; Synchronous digital hierarchy
multiplexing structure".
3 Definitions
For the purpose of this ETS, the definitions as defined in IEEE Standard 802.6 [6] shall apply.
4 Symbols and abbreviations
For the purpose of this ETS, the symbols and abbreviations as defined in IEEE Standard 802.6 [6] shall
apply.

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

SIST ETS 300 276 E1:2003
Page 8
ETS 300 276: March 1994
5 Physical layer convergence procedure for 622,080 Mbit/s CCITT
Recommendations G.707, G.708 and 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 622,080 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-4c virtual containers, and the VC-4-4c's are
transported using synchronous transport modules. A mapping of Asynchronous Transfer Mode (ATM)
cells into VC-4-4c 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-4c is
identical to the ATM cell mapping into VC-4-4c 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);
- the use of VC-4-4c for propagating the DQDB layer 125 μs timing along the DQDB buses;
- the Header Check Sequence (HCS) method shall be used 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], § 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 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 section 4.2 of IEEE Standard 802.6 [6]). Hence, the status parameter shall be 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) are 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-4c that consists of 9 rows by 1 044 octets. The VC-4-
4c has a nominal duration of 125 μs. The VC-4-4c frame rate shall provide the 125 μs timing information.
The VC-4-4c frames are transported between peer PLCPs by the SDH transmission system.
DQDB slots are mapped into the VC-4-4c as illustrated in figure 1. The VC-4-4c consists of one column
(nine octets) of Path Overhead (POH), three columns of unused octets plus a 9 row by 1 040 column
payload capacity.

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

SIST ETS 300 276 E1:2003
Page 9
ETS 300 276: March 1994
4 octets 1 040 octets
J1
VC-4-4c
B3
C2
G1
M1
9 rows
H4
M2
Z4
Z5
53 octets
VC-4-4c Path Overhead
DQDB slot
Figure 1: VC-4-4c PLCP mapping for DQDB
The DQDB slots are located horizontally (by row) in the VC-4-4c payload capacity with the slot boundaries
aligned with the VC-4-4c octet boundaries. Because the VC-4-4c payload capacity (9 360 octets) is not an
integer multiple of the DQDB slot length (53 octets), a slot is allowed to cross the VC-4-4c boundary. Slot
boundary indication shall be provided using the HCS method.
5 octet slot header 48 octet slot payload
HCS
3 octets covered
by HCS
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-4c
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-4c signal and slot
delineation, the slot payload shall be descrambled. The descrambler shall operate for the duration of the
assumed slot payload according to the derived slot delineation (see subclause 5.6.1.1). Operation shall be
suspended and the descrambler state shall be 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).

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

SIST ETS 300 276 E1:2003
Page 10
ETS 300 276: March 1994
5.3 PLCP path overhead field definitions
The first column of the VC-4-4c contains the path overhead octets. The following subclauses describe
each of the VC-4-4c 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)
For the definition of the J1 octet see ETS 300 147 [7].
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-4c. The computed BIP-8 is placed in the B3 octet of the current VC-4-4c. 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-4c, the second bit of the BIP-8 code calculates even parity over the second bit of
each octet in the VC-4-4c, etc. Therefore, the BIP-8 code provides for 8 separate even parity codes
covering the corresponding bit of each octet in the VC-4-4c.
5.3.3 Signal label (C2)
The C2 octet is allocated to indicate the construction of the VC-4-4c 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 bits 1 bit 3 bits
FEBE FERF Reserved
Far End Block Error Far End
Recieve
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-4c. 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) which persists for 2,5 ± 0,5 seconds, a FERF shall be generated on Bus y

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

SIST ETS 300 276 E1:2003
Page 11
ETS 300 276: March 1994
(y = B or A) by setting the fifth bit of the G1 octet to one (1). FERF is detected by a one (1) in the fifth bit of
the G1 octet for ten consecutive VC-4-4cs. 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 is
detected by a zero (0) in the fifth bit of the G1 octet for ten consecutive VC-4-4c's.
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 bits 6 bits
LSS Slot Offset Indicator
Link Status Signal
Figure 4: Multiframe indicator (H4) coding
The two most significant bits shall be used for the LSS code as described in section 11.3.2 of IEEE
Standard 802.6 [6]. The LSS shall be used to communicate information about the status of the
transmission link between two adjacent PLCP entities.
The LSS codes for the H4 octet are shown in table 1.
Table 1: LSS 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 o
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.