08 Tr3272eu00tr 0302 Mcf Configuration

8/12/2019 08 Tr3272eu00tr 0302 Mcf Configuration

1/63

MCF configuration Siemens

TR3272EU00TR_0302 2003 Siemens AG

1

Contents

1 Introduction to DCN (Data Communication Network) 3

1.1 General 4

1.2

NSAP structure 6

1.3 Routing basics 8

2 Management interfaces and supported stack profiles 10

3 Configuration of message communication function 13

3.1 MCF function group 14

4 Overhead access 25

4.1 General information 26

4.2 Overhead Cross-Connection function OHCC 30

4.3 Engineering order wire 38

5 Exercises 50

6

Solution 60

MCF configuration


2/63

Siemens MCF configuration

TR3272EU00TR_0302

2003 Siemens AG

2


3/63



3

1 Introduction to DCN (Data CommunicationNetwork)

I am LouisI am Peter

I am Elena

I am Tom

Fig. 1


4/63


TR3272EU00TR_0302

2003 Siemens AG

4

1.1 General

Network Management is the general term used to define a process by which one or

more management system, can control and manage equipment in the network.The Data Communication Network (DCN) provides facilities and connectionsbetween all components of a Telecommunications Management Network.

A basic requirement of the DCN is to provide a path that can deliver all control ormanagement messages from management system to the managed equipment andreports or requested data from managed equipment to the management system.

An SDH network is constructed so that the hardware meets the requirements of thetraffic network (the payload). The resulting topology need not necessarily match therequirements of the DCN network. For the DCN network, each SDH network elementmust be accessible from a central point.

The following network elements are directly accessible: All network elements in the station where the central supervision system is

located.

All SDH systems connected via STM-N connection(s) with each other and atleast one of these SDH systems acts as Gateway Network Element.

Network elements that do not meet any of the conditions listed above can beconnected via Embedded LAN.

The available DCN connections used in SDH networks are in general as follows:

Data Communication Channels (DCC) in SDH Section Overhead, DCCR(192Kbit/s) and DCCM (576Kbit/s).

Local Area Network (LAN) based on carrier sense multiple access/collisiondetect (CSMA/CD) protocol.

Wide Area Network (WAN), for example, SDH payload traffic via tributary of aSDH Add/Drop Multiplex with 2Mbit/s interface.

A DCN is usually designed to be resilient against failure of any single link or item ofequipment in a network. To provide such resilience, it is necessary that there are atleast two physically separate routes between entities that need to communicate with

one another.


5/63



5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Bridge

STM-16

STM-1

STM-1

STM-16 STM-1

Bridge

Leased Lines or

SDH Payload

as WAN connection

Central StationTNMS C or TNMS CT

Server

Central Station LANGNE

TNMS C or

TNMS CT

Client

Extended LANGNE

Remote Station

Embedded LAN

GNEs

STM-1

STM-1

DCN connections

over DCCR/M Channels

Fig. 2 DCN Connections


6/63


TR3272EU00TR_0302

2003 Siemens AG

6

1.2 NSAP structure

An NSAP (Network Service Access Point) address must be defined for each network

element. The NSAP address is used as NE identifier in the manageable network. Itmust be unique worldwide.

An NSAP address has a maximum length of 20 Bytes (40 characters) and generallyconsists of 2 parts: the Network-specific part and the Network Element specific part.

The first byte of the NSAP address is the Authority and Format Identifier (AFI). TheAFI indicates the format and coding applicable to NSAPs. There are a number offormats which are supported, such as:

AFI Recommendation

37 Address as per CCITT X.121.

53 Address as per CCITT X.121.

39 Address as per ISO 3166/DCC.

47 Address as per ISO 6523/ICD.

49 Local addresses (private).

Since Siemens is registered with the British Standard Institute as the operatingcompany / administrator of an international data network (ISO 6523 ICD, AFI - 47),Siemens has its own ICD (0099). Unless the customer has its own address format,this is the standard procedure for assigning NSAP addresses. The precise structureof the HODSP is defined in a separate paper Numbering Scheme for SiemensSupervisory Network, together with the specifications as to which address bytes arerequired for which purposes.

ICD: International Code Designator.

HODSP: High Order Domain Specific Part defined by administrative core.

DID: Domain ID defined by network authority.

SID: System Identifier defined by network authority.

SEL: NSAP Selector.


7/63



7

AFI IDI HO-DSP Domain System IDNSAP

SEL

Network-specific part Network Element specific part

1 Octet 2-7 Octets 0 -5 Octets 1-9 Octets 1-9 Octets 1Octet

NSAP Maximum Total Length = 20 Octets

Fig. 3 NSAP Structure

AFI Code Design. HODSP Domain SID SEL

47 2 Bytes 0-5 Bytes 1-9 Bytes 1-9 Bytes 1 Byte3 Bytes fixed max. 16 Bytes

e.g.

IDP DSP

AFI IDI

AFI ISO ICDFormat

HODSP Domain ID System ID NSAPSelector

47 0099 008000000 000000F101 0800061F7BF4 01

ISO 6523-ICD

Fig. 4 Example of ISO 6523-ICD NSAP address


8/63


TR3272EU00TR_0302

2003 Siemens AG

8

1.3 Routing basics

In Data Communication Network hiT 70xx series network elements function as IS-IS

routers. They support Level 1 and Level 2 routing.IS-IS is a dynamic routing protocol; it uses information gathered from the network toform routing tables, which are used to perform routing decisions. IS-IS allows for atwo-stage hierarchy within the routing domain, the Level-1 sub-domain and the Level-2 sub-domain. The Level-2 sub-domain consists of all Level-2 IS-IS routers; theLevel-1 sub-domain consists of multiple sub-domains of Level-1 routers, each sub-domain possessing a discrete address prefix (AREA). IS-IS uses the concept of linkmetrics when assessing the optimal route through a network. The assessmentprocess sums the metrics associated with the proposed links to workout the metricsum for the overall route.

Each network element knows the entire topology of the network. This enables each

network element to send a message to the recipient or to know via which neighbornetwork element the recipient can be reached. The SDH Systems using OSI routingalgorithm generate their dynamic routing tables automatically. There will be a primaryroute and a secondary route calculated and changed by SDH systems.

Routing Domain

The routing domain is a group of NEs that use the same routing procedure. Allthe devices of a network can form a single common routing domain if all devicesuse the same routing method. Devices with different routing methods (thisincludes; dynamic IS-IS routing, IS-IS broadcast routing and static routing) mustbe assigned to different routing domains. Static routing information, in the formof a Reachable Address Prefix (RAP) is required to connect routing domains

with different routing methods.

Sub Domain

A sub domain is a sub-network of IS using a common routing method. For level1 routing, a level 1 sub-domain consists of all IS in the routing area. This type ofsub domain is therefore a subgroup of the routing area. For level 2 routing, alevel 2 sub-domain consists of all related level 2 IS within a routing domain.

Level 1 Intermediate Systems

These systems route directly to systems within their own area. For destinationsoutside their own area they route towards the nearest level 2 Intermediatesystem. These systems use the System ID part of the NSAP to route the

packets.Level 2 Intermediate Systems

Level 2 systems route towards a different routing area, or another routingdomain. These systems use the first part of the NSAP address to route thepackets. These systems also act as Level 1 intermediate systems within theirown routing area.


9/63



9

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TNMS CT

STM-16

STM-1

STM-16 STM-1

GNE

Embedded LAN

STM-1

STM-16 STM-1

STM-16

Other Routing

Domain

Routing Domain

Level 2Subdomain

Level 1Subdomain

Level 1Subdomain

L1 IS

L1 IS

L1 IS

L1 IS

L1 IS

L1 IS

L1 IS

L1 IS

L1 IS

L1 IS

L1 IS

L1 IS

L1/L2 IS

L1/L2 ISL1/L2 IS

L1/L2 IS

RAP RAP

Area part of NSAP:470099002760000c0000000040

Area part of NSAP:470099002760000c0000000060

Fig. 5 Routing Domain


10/63


TR3272EU00TR_0302

2003 Siemens AG

10

2 Management interfaces and supportedstack profiles

Supported Management Interfaces

The SURPASS hiT 70 series offers a rich set of element management interfaces forlocal and remote access using different stack profiles:

LCT on local F-interface

LCT over Q-interface

NCT over Q-interface

TNMS-C over Q-interface

Supported Stack Profiles

The SURPASS hiT 70xx series provides physical access (Layer 1) to themanagement functionality via 3 different types of interfaces:

DCC channels:

hiT 7070:30 DCC channels embedded in the SDH overhead (DCCM, DCCR,HCOC3, HCOC9, F2-Byte)

hiT 7050:4 DCC channels embedded in the SDH overhead (DCCM, DCCR,HCOC3, F2-Byte)

WARNING

The SDH drawers O155-2 and O622-2 do not support the F2 and the HCOC3byte termination due to hardware constraint.

Ethernet Interface(s):

hiT 7070:Three external Ethernet interfaces (Q_EXT, Q_F2 and Q) connectedby an internal switch to one internal SCOH Ethernet interface

hiT 7050:One external Ethernet interface (Q)

Serial Interface:

One Serial RS232 interface (F)

The SURPASS hiT 70xx series supports two different and independent actingprotocol stacks:

An OSI stack including TP0, TP4, CLNS, ES-IS, IS-IS, LAPD and LLC1managed with QST, which is able to interact with already deployed Siemensstack implementations

A TCP/IP stack including TCP, UDP, IP, OSPF, PPP and Ethernet framingdefined in RFC894 managed with SNMP


11/63



11

Part ofLinux Kernel

ZebOS OSPFdaemon

Part of BASW

TP4

Layer 5..7

Layer 4

Layer 3

Layer 2

Layer 1

OSPFRouting

protocol

Marben Stack

Part of ASW

SNMP/QST

wrapper

SNMP

masteragent

OSPF

subagent

IP MIB2

subagentTelnet

server

Enterprise

subagent

CIF(QST agent)

Hardware

Part of BASW

hiT 70xx protocol stackhiT 70xx protocol stack

UDP TCP

IP

RFC894

RS232

driver

Ethernet

driver

DCC

driver

CLNP ES-IS/IS-IS

LAPDLLC1

TP0

RFC1006

PPP

Multiplexer

Q, Q_F2, Q_EXT F DCCR, DCCM, F2, HCOC3, HCOC9

Fig. 6 hiT 70xx protocol stack

Accessible parts of functionality

Application

Protocol(Layer 57)

Transport

Protocol(Layer 4)

Network

Protocol(Layer 3)

Data link Protocol(Layer 2)

LCT F-interfaceAll functionality specified in QSTincluding SNMP over QST for

management of IP and OSPF functionality

QSTTP0 overTCP (RFC

1006)

IP- PPP over RS232using predefined

IP addresses

LCT Q-interface, NCT,

TNMS-C and othermanagement systems

supporting the QST

interface

All functionality specified in QST

including SNMP over QST for


QST TP4 CLNS

- LAPD over DCC

- LLC1 over

Ethernet

IP based management

applications

All functionality specified in QST

including SNMP over QST for


QST

TP0 over

TCP (RFC

1006)

IP- PPP over DCC

- RFC894

Combinations of Management Interfaces and Stack ProfilesCombinations of Management Interfaces and Stack Profiles

Fig. 7 Supported Combinations of Management Interfaces and Stack Profiles


12/63


TR3272EU00TR_0302

2003 Siemens AG

12


13/63



13

3 Configuration of message communicationfunction


14/63


TR3272EU00TR_0302

2003 Siemens AG

14

3.1 MCF function group

All required MCF settings could be done via the "Message Communication

Function" window. The general design is the same for hiT7070 and hiT7050 NetworkElement types. The window is grouped into five function groups where the actualsettings can be viewed or modified.

Stack Parameters:

Settings for Layer 3, Layer 4 and routing principles of the OSI protocol.

Ethernet:

Settings for Q-Interface (Layer 2) and Reachable Address Prefixes (RAP)related to the communication over LAN.

DCC:Settings for DCC and RAP related to the communication over STM-N lines.

CLNS:

This is where the information about collected routing information (ConnectionLess Network Service, CLNS) can be obtained.

Transport Connections:

This is where the information about active connections to the remote systemscan be checked.

"Message Communication Functions" window can be opened as follow:From NE Main window select (RMB) "SCOH" (hiT 7070) or "MFP1" (hiT 7050)function symbol and from opened Pull Down menu select "Configuration -> MCF".

WARNINGThe settings for the MCF parameters on the network elements are specified bythe Network Planning Department. All data in this window should not bechanged after commissioning, unless the DCN topology has been changed. Ifin doubt, the default values should be retained.


15/63



15

Fig. 8 Opening Message Communication window hiT 7070

Fig. 9 Opening Message Communication window hiT 7050 FP1


16/63


TR3272EU00TR_0302

2003 Siemens AG

16

3.1.1 Stack parameters

Layer 4 (Transport):

The real propagation time of PDUs within the network has to be less than thereaction times of the timer values set in layer 4. The layer 4 timer values needs to bethe same for all NEs within the same routing domain.

Window Timer:

Time of inactivity. After the timer will be expired connection will be terminated.Inactivity means, that neither data nor acknowledge data packets (PDUs) werereceived.

Maximum No. of Transmissions:

Specifies how often the PDU will be retransmitted in case the retransmissiontimer has been expired.

Retransmission Time:

If a sent PDU is not acknowledged in this time, it will be retransmitted.

Layer 3 (NSAP):

NSAP address of the NE:

The complete NSAP length is divided into a Domain Area Address part andSystem ID (SID) part, which are entered separately.

WARNINGThe NSAP address must be unique.


17/63


18/63


TR3272EU00TR_0302

2003 Siemens AG

18

3.1.2 Ethernet

This is where the data communication over Ethernet port can be configured orproved.

Configuration:

These parameters are used for the configuration of the Q-Interface of the NE.

Traffic Mode:

Select the traffic mode according to the planning data (default is OSIIP).

External Domain:

Default value no mean ISIS Routing is enabled. The setting yes disables theISIS routing. This might be useful to block ISIS Routing in case if only staticrouting over Ethernet connection needs to be used.

L1/L2 Intermediate System Priority:

Priority of the system for being selected as the designated IS on the subnetwork.

Level 1/2 Default Metric:

Each output port of an IS gets a metric value in the range 1 63. With the helpof the metrics, the shortest path can be found. All metrics along a path arecumulative. The PDUs will be sent over the path with the lowest metric. Themax. value in a routing table is 1023, any "longer" routes can not be used.

MAC Ethernet Address:This is the setup of Layer 2 (LAN-MAC) address. This address is specified bythe Network Planning Department.

MCF Linkage State:

MCF Linkage state is enabled if communication on layer 2 is ok.

Reachable Addresses:

This is where the list of configured Reachable Address Prefixes can be validated.RAP (Reachable Address Prefix) is used to connect Routing Domain, which does notsupport the ISIS routing. On the LAN Reachable Address Prefix (RAP) needs a "Sub-network Point of Attachment" (SNPA). This is the LAN-MAC address of thedestination system.

WARNINGEvery RAP within an NE must be unique and must not be a part of anotherRAP.


19/63



19

Fig. 11 Ethernet Port configuration window

Whit the use of the "Add" or "Modify" buttons, "Ethernet Reachable AddressAdd" or "Ethernet Reachable Address Modify" windows can be opened where youcan create a new entry in the reachable address list or modify an existing one.

Address Prefix:

This is where the Reachable Address Prefix can be set up.

Default Metric:

This is the setup of metric value for that interface. With the help of the metrics,the shortest path can be found.

Default Metric Type:

Possible values: internal or external. If metric type is set to Internal the RAPmetric will be used to calculate the path. Only in case a link with metric-typeInternal is no more available the link with the type External will be used.

SNPA Address:

"Sub-network Point of Attachment" (SNPA) is the LAN-MAC address of thedestination system.


20/63


TR3272EU00TR_0302

2003 Siemens AG

20

3.1.3 DCC

This is where the data communication over DCCR, DCCM, F2, HCOC3 or HCOC9(only for hiT7070) channels can be configured or verified. The settings for this serialcommunication channels is similar to the Ethernet settings. If necessary, RAPs mayalso be set for communication over DCCR/DCCM/F2 to Routing Domain, which doesnot support the ISIS routing, but without SNPA.

DCC List:

In this window, you can create or delete connections between DCC channels and theDCCM, DCCR, F2, HCOC3 or HCOC9 ports. Up to 30 connections (max. 20 DCCM)can be set up in case of hiT 7070 or up to 4 connections (max. 2 DDCM) in case ofhiT 7050.

To set up a new connections the following needs to be done:

1. Select (LMB) in the "DCC List" field a free DCC Channel.

2. In the "New DCC Cross Connection" field select "Port Type" (DCCR, DCCM,F2, HCOC3 or HCOC9) and "Port" (define the SDH port where DCCR, DCCM,F2, HCOC3 or HCOC9 channel should be used).

3. Confirm settings with the "Connect" button.

If the existing connections needs to be modified:

4. Select (RMB) the connection that needs to be modified.

5. From open Pull Down menu select "Configuration" and "DCC LinkageConfig" window will be opened.

The following parameters can be modified or confirmed in the "MCF DCC LinkageConfiguration" window.

External Domain:

Default value no mean ISIS Routing is enabled. The setting yes disables theISIS routing. This might be useful to block ISIS Routing in case if only staticrouting over this DCC connection needs to be used.

Level 1/2 Default Metric:

Each output port of an IS gets a metric value in the range 1 63. With the helpof the metrics, the shortest path can be found. All metrics along a path arecumulative. The PDUs will be sent over the path with the lowest metric. The

max value in a routing table is 1023; any "longer" routes cannot be used.

T200 Time:

This timer is responsible for layer 2 and should be the same for neighboringNetwork Elements. If the values are very different the connection will beunstable.


21/63



21

1

3

2

5

4

Fig. 12 DCC Configuration window

Traffic Mode

This attribute determines if this DCC channel will be used for OSI traffic, for IPtraffic or for both types of traffic. Possible values are: IP, OSI, OSIIP. Select thetraffic mode according to the planning data.

Interface Type:

Possible values are "User" or "Network". This parameter is used to set master -slave behavior on DCCR, DCCM, F2, HCOC3 or HCOC9 connections. Bothends of the connection must have the alternative values (User Network orNetworkUser) otherwise the communication over this DCCR, DCCM, F2,HCOC3 or HCOC9 connection is not possible.

Line Code:

Displays the NRZ (non return to zero) line code. It cannot be changed.

MCF Linkage State:

MCF Linkage state is enabled if communication on layer 2 is ok.

Reachable Addresses:

Here the list of configured Reachable Address Prefixes can be validated. Thesettings for the RAPs are similar to the settings in the Ethernet function group, butwithout SNPA.


22/63


TR3272EU00TR_0302

2003 Siemens AG

22

3.1.4 Transport connections

This is where the information about active connections to the remote systems can beverified.

Remote NSAP Address:

This is where the NSAP Address of the connected TNMS CT or TNMS C can bechecked.

Remote T Selector:

T Selector used by the remote manager for this transport connection.

Local T Selector:

T Selector used by this NE for this transport connection.

Connection Type:

Direction of the set-up transport connection. (Outgoing = sent from the localsystem, Incoming = sent from the remote system).

Window Timer:

Displays Time of inactivity. After time of inactivity will be expired connection willbe terminated. Inactivity means, that neither data nor acknowledge data packets(PDUs) were received.

Maximum No. of Transmissions:

Displays how often the PDU will be retransmitted in case the retransmission

timer has been expired.Retransmission Time:

Displays the time after the PDU is repeated if there is no answer from theopposite station.


23/63



23

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fig. 13 Transport Connection information window


24/63


25/63



25

4 Overhead access


26/63


TR3272EU00TR_0302

2003 Siemens AG

26

4.1 General information

The following overhead access functions are provided:

Access to SOH and VC-4 F2 POH Overhead bytes and DCC channels of theSTM-n interfaces (SOH #1)

Access to 4 auxiliary external interfaces V.11 / X.21, bidirectional (supported byhiT 7070 only)

Engineering Order Wire Conference (EOWC), including Ring Manager for ringoperation

2-wire handset for EOW

4-wire E&M interface for EOW (supported by hiT 7070 only)

Cross connect function (switching) of SOH bytes (including transparent DCC

connections) and connect function to MCF, EOWC and Ring Manager.WARNINGAccess to the V.11 / X.21 auxiliary interfaces as well as EOW support requiresadditional HW (OHM module for hiT 7070, EOW module for hiT 7050) to beinstalled on the controller cards (SCOH, MFP1).

Accessible Overhead Bytes

The table below gives an overview to the accessible overhead bytes, which aredefined for use as overhead channels with SURPASS hiT 7070 and 7050.

EOW channels can be realized with the bytes E1 and/or E2

An RSOH user definable channel can be realized with the byte F1

DCCR channels can be realized with the bytes D1 D3

DCCM channels can be realized with the bytes D4 D12

Special ECCs can be realized with the byte F2

A set out of the MSOH bytes is defined for use as one high capacity channeland/or for 64kb/s channels accessible via X.21 interfaces


27/63



27

4 external interfaces accessible at the COPAV.11 / X.21 (SCOH)

Ring ManagerRM (SCOH)

Engineering Order Wire ConferenceEOWC (SCOH)

F2VC-4 POHs in LO SF TPs

E2 (9,7,1); Z1 (9,2,1) and (9,3,1); Z2 (9,4,1) and (9,5,1)

Unused: (5,5,1), (5,6,1), (5,8,1), (5,9,1), (6,2,1), (6,3,1), (6,5,1), (6,6,1), (6,8,1), (6,9,1), (7,2,1),

(7,3,1), (7,5,1), (7,6,1), (7,8,1), (7,9,1), (8,2,1), (8,3,1), (8,5,1), (8,6,1), (8,8,1), (8,9,1)

NU: (9,8,1) and (9,9,1)

HCOC3 Group 1: combined CP for bytes (5,5,1), (5,6,1), (5,8,1)





HCOC27: combined CP for bytes (5,5,1), (5,6,1), (5,8,1), (5,9,1), (6,2,1), (6,3,1), (6,5,1), (6,6,1),(6,8,1), (6,9,1), (7,2,1), (7,3,1), (7,5,1), (7,6,1), (7,8,1), (7,9,1), (8,2,1), (8,3,1), (8,5,1), (8,6,1),

(8,8,1), (8,9,1), (9,2,1), (9,3,1), (9,4,1), (9,8,1) and (9,9,1)

DCCM: combined CP for bytes (6,1,1), (6,4,1), (6,7,1), (7,1,1), (7,4,1), (7,7,1), (8,1,1), (8,4,1)and (8,7,1)

HCOC9 Group 1: combined CP for bytes (5,9,1), (6,2,1), (6,3,1), (6,5,1), (6,6,1), (6,8,1), (6,9,1),(7,2,1) and (7,3,1)

HCOC9 Group 2: combined CP for bytes (7,9,1), (8,2,1), (8,3,1), (8,5,1), (8,6,1), (8,8,1), (8,9,1),

(9,8,1) and (9,9,1)

MSOH CPs in each

termination point

E1 (2,4,1); F1 (2,7,1); NU (2,8,1); Unused (3,8,1)DCCR: combined CP for bytes (3,1,1), (3,4,1) and (3,7,1)

RSOH CPs in eachtermination point

hiT7070

Overhead Connection Points for hiT 7070Overhead Connection Points for hiT 7070

Fig. 15 Overhead Connection Points for hiT 7070

Note: The SOH numbering scheme (a, b, c) defines:

the row (a)

the multi-column of an STM-1 channel (b)

the STM channel within the STM-N signal (c)


28/63


TR3272EU00TR_0302

2003 Siemens AG

28

Ring masterRM (MFP1)

Engineering Order Wire ConferenceEOWC (MFP1)

F2VC-4 POHs (HO path TPs)

E2 (9,7,1); Z1 (9,2,1) and (9,3,1); Z2 (9,4,1) and (9,5,1)Unused: (5,5,1), (5,6,1), (5,8,1), (5,9,1), (6,2,1), (6,3,1), (6,5,1), (6,6,1), (6,8,1), (6,9,1), (7,2,1),

(7,3,1), (7,5,1), (7,6,1), (7,8,1), (7,9,1), (8,2,1), (8,3,1), (8,5,1), (8,6,1), (8,8,1), (8,9,1)

NU: (9,8,1) and (9,9,1)


DCCM: combined CP for bytes (6,1,1), (6,4,1), (6,7,1), (7,1,1), (7,4,1), (7,7,1), (8,1,1), (8,4,1)

and (8,7,1)

MSOH CPs in eachtermination point

E1 (2,4,1); F1 (2,7,1); NU (2,8,1); Unused (3,8,1)DCCR: combined CP for bytes (3,1,1), (3,4,1) and (3,7,1)

RSOH CPs in eachtermination point

hiT 7050

Overhead Connection Points for hiT 7050Overhead Connection Points for hiT 7050

Fig. 16 Overhead Connection Points for hiT 7050

Note: The SOH numbering scheme (a, b, c) defines:

the row (a)

the multi-column of an STM-1 channel (b)

the STM channel within the STM-N signal (c)


29/63



29

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Framing bytes

Bit Interleaved Parity

for bit error monitoring

Section trace

(STM identifier)

Data channels

Order wire

A1, A2

B1, B2

J0

D1-D12

E1, E2

Automatic protection switching

F1

K1, K2

M1

S1

Z1, Z2

User channels

Remote error indication

Sync. status (timing marker)

spare

for national use

Media dependent bytes

AU Pointer

RSOH

MSOH

B1

B2 B2 B2

D1 D2 D3

D4 D5 D6

D7 D8 D9

D10 D11 D12

E1 F1

K2K1

S1 E2

J0

Z1 Z1 Z2 Z2 M1

H1

A1 A1 A1 A2 A2 A2

H2 H2H1 H3 H3 H3H1 H2

Section overhead assignment acc. G.707Section overhead assignment acc. G.707

a=1

a=2

a=3

a=5

a=6

a=7

a=8

a=9

b=1 b=2 b=3 b=4 b=5 b=6 b=7 b=8 b=9

column (b)

row (a)

Fig. 17 Section overhead assignment acc. G707


30/63


TR3272EU00TR_0302

2003 Siemens AG

30

4.2 Overhead Cross-Connection function OHCC

4.2.1 Overview

Overhead bytes can be cross-connected by means of the overhead cross-connectionfunction OHCC. The granularity is 64 kbit (one byte).

The overhead cross-connection function allows the following flexible connections:

MCF using DCCR bytes or DCCM bytes or the F2 byte

EOWC using E1 byte and/or E2 byte

4-wire analogue interface using E1, E2 bytes.

X.21 interfaces using bytes according

RSOH, MSOH and POH bytes according

The table shown in Fig. 19 gives an overview to the possible overhead cross-connections. Accessible via the external, physical, interfaces X.21 are the bytes E1,F1, E2, NU, unused and F2.

TIPThe connection between EOWC and the 2-wire handset interface is not done via theOHCC.


31/63



31

OH

BytesEOWC

MCF

OHCC

function

#

A/D Coverter,RingingGenerator etc.

2-wire analogueEOW handsetinterface *

A/D Coverter,optional E&Msupport etc.

4-wire analogueinterface *

2-wire EOWhandset

digital

interface

* = External, physical interfaces

**= Core only

X.21

interfaces **

fix connectedto EOWC

digitalinterface

Overhead Cross-Connection Function OHCCOverhead Cross-Connection Function OHCC

Fig. 18 Overhead Cross-Connection Function OHCC

XRM

XXXF2

XXXXHCOC9

XXXXHCOC3

XXXXDCCM

XXXXDCCR

XXHCOC27

XXXF1, Z1, Z2, NU,

Unused

XXXXE1, E2

V

.11/

X

.21

E

OWC

F2

M

CF

H

COC9

H

COC3

D

CCM

D

CCR

H

COC27

F1,Z1,Z2,

N

U,Unused

E

1,E2Connection

Point

CP1/CP2

Possible OH / DCC connectionsPossible OH / DCC connections

Fig. 19 Possible OH / DCC connections


32/63


TR3272EU00TR_0302

2003 Siemens AG

32

4.2.2 Auxiliary channels (hiT 7070 only)

64kb/s-Auxiliary Channels built with SOH Bytes(hiT 7070)

Fig. 20 gives an overview to the use of SOH bytes with SURPASS hiT 7070 as64kb/s-overhead channels through a network. In the given example an overhead byteout of the MSOH shall be used to transfer data from NE 4 to NE 1 (and of course not shown here for simplification of description- vice versa). An MSOH byte has beenconfigured, because in this example the OH path shall be protected between NE 3and NE 2 by a linear 1+1 MSP.

The incoming data are connected via a physical X.21 interface to the OHCC of NE 4.The data are transported via a NE-internal transport mechanism for OH bytes to thecorresponding interface and inserted into the configured byte of the MSOH in NE 4.In NE 3 the used OH byte is extracted from the MSOH and transmitted to the OHCC.In transmit direction the OHCC broadcasts the OH byte via the NE-internal transport

mechanism to the interfaces of the working port and the protecting port. There it isinserted into the configured OH byte. (Remark: In opposite direction the OHCCselects -triggered by the MSP function- the OH byte from the active line). The MSPfunctionality in NE 2 is inverse corresponding to NE 3. The selected OH byte isinserted via the OHCC into the MSOH of the outgoing signal to NE 1. In NE 1 theextracted OH byte is cross-connected via the OHCC to the physical X.21 interfaceand forwarded to the data sink.

64kb/s-ECC Channel built with the POH Byte F2

OH access of POH Byte F2 at path terminating points (structured VC-4) is supportedonly at LO switching fabric (hiT 7070) or at certain STM-N cards in hiT 7050.

If network termination equipment like SMA1K or SURPASS hiT 7050 shall becontrolled via an ECC a problem raises if this ECC shall be piped through a networkof another carrier (see Fig. 21). It is not possible to use DCCR or DCCM becausecarrier A cannot configure the necessary OH cross-connections for the DCC withinthe NEs in the network of carrier B. One way to control this remote NE is to use theF2 byte within the VC-4-POH because the VC-4 is transported transparently throughthe network.

Fig. 21 depicts this situation. With SURPASS hiT 7070/7050 it is possible to controlthe remote NE via an ECC built with the F2 byte with a transport capacity of 64kb/s.The OS is connected to an SURPASS hiT 7070/7050 within the area of carrier A.Using the F2 byte the remote NE (e.g. SMA1K) can be controlled remotely via the

area of carrier B.


33/63



33

Location B

Router A

Location A

Router A

OHCC

NE3

OHCC

NE2

OHCC

NE1

OHCC

NE4

1+1 MSP

Overhead Path using an MSOH Byte and MSPOverhead Path using an MSOH Byte and MSP

X.21 X.21

Working

Protecting

Multiplex Section Overhead Byte

Multiplex Section Overhead Byte

Fig. 20 Example for an Overhead Path through a Network using an MSOH Byte and MSP

Remote NE

(e.g. SMA1K)

controlled byCarrier A

F2-byte cross-connected

via OHCC to MCF

MCF

Carrier A

Use of POH Byte F2Use of POH Byte F2

Carrier B

TNMS

SMA1K

SMA1K

MCF

VC-4 pathF2-byte in POH

used as ECC

Fig. 21 Use of POH Byte F2


34/63


TR3272EU00TR_0302

2003 Siemens AG

34

DCC Transparency Channels

In addition to the possible cross-connections DCC -> MCF, the OHCC in SURPASShiT 7070 offers the possibility to cross-connect DCC to DCC and DCC to NU-

and/or unused OH-bytes (see Fig. 19). This feature (DCC Transparency) can beused to realize a DCCpipe through a network. Because these DCC-bytes are cross-connected by means of the OHCC functionality from port to port directly, thesechannels are bypassed to the MCF; i.e. the MCF in the intermediate NE are notloaded by this DCC.

Fig. 22 shows an example how a DCC Transparency Channel can be used. Comingfrom Carrier 1 an STM-N signal carrying a DCCM channel is connected to theSURPASS hiT 7070 ring of Carrier 2. This carrier provides the transparent transportof the DCCM channel through his network. In NE1 the incoming DCCM channel iscross-connected to (e.g.) the HCOC9 Group2. This Group of OH bytes transports theDCCM channel from NE1 to NE2. Within the intermediate NEs appropriate cross-

connections for this group of OH bytes have to be configured. In NE2 -in outgoingdirection- the HCOC9 Group 2 is cross-connected to the DCCM channel of theoutgoing STM-N signal to Carrier 1 again. In this way a transparent transport of DCCinformation for the carrier 1 through the network of carrier 2 is realized.

According to the actual need for transport capacity the Groups of OH-bytes can beused per port at the same time as shown in Fig. 23.


35/63



35

hiT 7070 Ring

Carrier 2

NE1 NE2

Carrier 1 Carrier 1

Cross-Connection

DCCM HCOC9

Cross-Connection

HCOC9 HCOC9

Cross-Connection

HCOC9 DCCM

STM-N STM-N

DCCM

HCOC9

DCC Transparency ChannelsDCC Transparency Channels

Fig. 22 Example for the Use of DCC Transparency Channels

(9,9,1) HCOC3 Group5HCOC9 Group2

(9,8,1)

(9,4,1)

(9,3,1)

(9,2,1)

HCOC3 Group5(8,9,1)

(8,8,1)

(8,6,1) HCOC3 Group4

(8,5,1)

(8,3,1)


HCOC9 Group2

(7,9,1)

(7,8,1)


(7,5,1)

(7,3,1)

(7,2,1)

(6,9,1)

(6,8,1)(6,6,1)

(6,5,1)

(6,3,1)

(6,2,1)

HCOC9 Group1

(5,9,1)

(5,8,1)

(5,6,1)

HCOC27

1728kb/s

HCOC3 Group1

(5,5,1)

OH-Bytes

Fig. 23 Group Definitions for DCC Transparency Channels and HCOC


36/63


TR3272EU00TR_0302

2003 Siemens AG

36

High Capacity Overhead Channel (HCOC) (hiT 7070 only)

For management of a 3rd party equipment, one or two auxiliary OH channels with aconfigurable transport capacity of up 1728 kbit/s can be configured per NE. To realize

this feature certain groups of MSOH bytes are predefined for this purpose. MSOHbytes are used because of the protection capability and the number of free bytes.

Four transport capacities are predefined: 64 kb/s, 192kb/s, 576kb/s, and 1728kb/s. AHCOC can be used (beside other possibilities) as a DCC pipe for a DCN backbonefrom router to router through a network (see Fig. 24). The limited number of freeMSOH bytes gives the maximum transport capacity. Access to these HCOC isprovided via the OHCC and the physical X.21 interfaces.

Because the used MSOH bytes are terminated in every NE, they have to be cross-connected from port to port within all intermediate NE. Therefore:

HCOC can only be used in carrier-own networks; i.e. it is not possible toconfigure a path through a network of any other carrier.

All intermediate NE must provide OH-connectivitys for all used MSOH-bytesaccording to the table shown in Fig. 23.

In the example shown in Fig. 24 a DCC-pipe is configured through a networkbetween router A and router B. For protection purposes two HCOCs are configuredusing the same NEs at the interchange points. The routers are connected via twodata paths, the working path between the NE-ports A A and the protecting pathbetween the NE-ports B B.

Because the interchange points for the working and the protecting path are located inthe same NEs (NE 1 / NE 5), two HCOCs are to be configured in these two NEs. Adisadvantage of this configuration is that the internal transport mechanism for OH

bytes is loaded with two HCOC capacities and if NE 1 or NE 5 fails totally, the wholedata pipe is interrupted.

A possible configuration that avoids these disadvantages is the shown in Fig. 25. Itassumes that the NEs 1 and 7 are accessible at the same location. The same holdsfor the NEs 6 and 11. Regarding the data paths the difference to Fig. 24 is that thedata are feed to the network via two different NEs. Iin this case the NE internaltransport mechanism for OH bytes is loaded with one HCOC capacity only. Furtheron the pipe is not interrupted, if one of the feeding NEs fails totally.


37/63



37

Location A Location B

NE6 NE8

NE7

NE9

NE1

NE2 NE4

NE5

NE3

OHCC

X.21 X.21

OHCC

X.21 X.21

Protection path

Working path

port A port A

port B port B

Router A Router B

Interchange pointInterchange point

DCC Pipe using two HCOCs for Protection PurposesDCC Pipe using two HCOCs for Protection Purposes

Fig. 24 DCC Pipe for a Third Party Equipment through a Net using two HCOCs for Protection Purposes

NE2 NE4

NE3

NE5NE1

NE8 NE10

NE6

NE9

OHCC

X.21

OHCC

X.21

Protection path

Working path

Router A Router BInterchange pointInterchange point

DCC Pipe using two different NEs for ProtectionDCC Pipe using two different NEs for Protection

NE7

X.21

OHCC

NE11

OHCC

X.21

Location A Location B

Fig. 25 DCC Pipe for a Third Party Equipment using two different NEs for feeding to the Network


38/63


TR3272EU00TR_0302

2003 Siemens AG

38

4.3 Engineering order wire

4.3.1 Introduction

The engineering order wire channels are transmitted via the EOW bytes E1 and E2acc. to ITU-T. They can be accessed via the overhead cross-connection and EOWconnection functions and one handset with a two wire analogue interface. In additiona 4-wire analogue telephone interface is supported (voice mode only). The telephoneconference circuit allows the interconnection of external speech channels (e.g. fromEast and West line signals as well as tributary signals; 2-wire and 4-wire interface)so that each subscriber is connected with every other subscriber.

TIPCorrect connection of the EOW channels into a conference or in a ring structure isthe responsibility of the system administrator.

3-digit selective, group and conference call numbers are supported in which case thedirectory numbers 000, XY0 and X00 are reserved for collective call and group call(see Manual Operator Guidelines OGL).

Note The handset can be connected to the EOWC via the physical analogue 2-wire EOW interface.

Note The used E bytes are broadcasted to/received from all ports to which theEOWC is cross-connected via the OHCC function.

Fig. 26 shows an example how an EOW line can be configured through a network. Inthis example it is assumed, that the E2 byte shall be used for the line from NE1, NE3up to the NE8 whereas the E1 byte shall be used for the line between NE1 and NE2.

EOW shall be used at the locations 1, 2, 5, 7 and 8.

NE1: EOWC is cross-connected viaOHCC with:E2 byte of port 1E1 byte of port 2

NE5: EOWC is cross-connected viaOHCC with:E2 byte of port 1OR(see Note below)E2 byte of port 2

NE2: EOWC is cross-connected viaOHCC with:E1 byte of port 1


E2 byte of port 2E2 byte of port 3




39/63



39


E2 byte of port 3



40/63


TR3272EU00TR_0302

2003 Siemens AG

40

NE 3

NE 1

NE 8

NE 4

NE 7

NE 6

EOW-Path: NE 2

1

2

8

Port1

Port2

Port1

Port 2

Port 1

Port 2

Port3

Port

2

Port

1

Port1

Port2

Port 2

Port 1

Port3

Port2

Port 1

# = is cross connected to

E2 # EOWC

via OHCC

E2 # EOWC

via OHCC

E1 # EOWCvia OHCC

E1 # EOWC

via OHCC

E2 # EOWC

via OHCC

E2 # EOWC

via OHCC

E2 # EOWC

via OHCC

E2 #

EOWCvia

OHCC

E2 # EOWC

via OHCC

E2 # EOWC

via OHCC

E2 # EOWCvia OHCC

7

5

NE 5

*

*#

= optional to avoid a closed EOW-loop

EOW Path through a NetworkEOW Path through a Network

Ring Manager

Note The handset can be connected to the EOWC via the physical analogue 2-wire EOW interface.

Note The used E bytes are broadcasted to/received from all ports to which the

EOWC is cross-connected via the OHCC function.Fig. 26 Example for an EOW Path through a Network

TIPNE5 can also take part of the EOW line, but in this example the EOW path isinterrupted here by means of the activated ring manager function in order to avoid anEOW-loop. I.e., the EOWC may not be cross-connected to the E2 bytes of both ports1 and 2, but to one port only. This works as an EOW protection in the case of a spanfailure.

Example: If the E2 byte from port 2 is used and a line within the ring fails, the E2 byte

from port 1 will be used for EOW automatically.


41/63



41

Engineering Order Wire Conference (EOWC)

In SURPASS hiT 7070/7050 design, one EOWC, which belongs to a party lineconsisting of one or several EOW channels, is supported. All EOW communication

channels are linked together in the network element by means of the EOWC function.Necessary data processing, as adding and subtracting the adequate E1/E2 bytes,supervision of all EOWC-inputs for static bytes, etc. are performed by the EOWCfunctionality within the NE.

Several subscribers can use the conference (one conference is supported) at thesame time. In the SURPASS hiT 7050 maximum 4 lines can attend the conferencecall, and in the SURPASS hiT 7070 up to 8. The sum of the incoming digital voicesignals of all ports, minus the incoming digital voice signal of the own port (highreturn loss) is distributed to all outgoing ports. Internally the data are processed aslinear PCM code (A-law according to ITU-T G.711).


42/63


TR3272EU00TR_0302

2003 Siemens AG

42

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

EOWCA/D Coverter,RingingGenerator etc.

2-wire analogueEOW handsetinterface *

A/D Coverter,optional E&Msupport etc.

4-wire analogueinterface **

2-wire EOWhandset

digital

interface

* = External, physical interfaces

**= Core only

X.21

interfaces **

Fixed

connection

to EOWC

digital

interface

OHCC and EOWC functionOHCC and EOWC function

RM

OHMUX

function Configurableconnection

to EOWC

OHM module

on SCOHOH

Bytes

MCF

OHCC

function

Fig. 27 Overhead Cross-connection function OHCC and Engineering Order Wire Conference function EOWC


43/63



43

EOW in Networks with Ring-Configuration / Ring manager

An automatic EOW ring-manager is supported only for SURPASS hiT 7070 only. The7050 has restricted functionality. The ring manager is called ring master, and in the

case of fiber break it has to be reconfigured by hand.If rings are supported, an EOW ring manager must be implemented in order toprovide EOW protection. In case of STM ring networks the EOW network must still bea linear chain. This is accomplished by means of the EOW ring manager function inone NE of the ring. The ring manager disconnects the EOW channels between eastand west line interfaces.

The EOW network will be a linear chain starting at one side of the NE with the ringmanager and ending at the other side of the same NE. In case of a ring failure thering manager has to connect the east and west EOW channels in order to have stillEOW access to all NEs of the ring. This is accomplished by comparing the signallevels of the EOW channels from east and west side. If the mean amplitudes of both

sides are the same, the ring is working correctly and east and west sides aredisconnected. If they are different, a ring failure has occurred and east and westsides are connected together.

TIPWithout an EOW ring manager it is still possible to operate an EOW in a ring. In thiscase the EOW has to be configured as a linear chain with the result that the EOW isnot protected in case of span or node failures. But note, this is exactly the situation,where an EOW connection should be available for the service staff immediately,without the need of reconfiguration the EOW.

If the ring manager shall be activated, it has to be inserted in an EOW loop byconnecting the E1/E2 byte of one line interface to the ring manager and the ringmanager to the EOW conference.

Fig. 28 and Fig. 29 show an example with a 4-node ring. All connections between thenetwork elements represent E1/E2 data transmission channels. So, in case of aconfigured ring of NEs, the EOW (E1/E2 byte data transmission) has to beinterrupted at exactly one node (EOW ring manager function).


44/63


TR3272EU00TR_0302

2003 Siemens AG

44

EOW channels disconnected by ring manager

2-wire handset

connection

Ring manager (RM) function

OH/EOW

hiT 7070

OH/EOW

hit7070

OH/EOW

OH/EOW

hiT 7070

hiT7070

RM function in a fault-free hiT 7070 ringRM function in a fault-free hiT 7070 ring

Fig. 28 Ring manager function in a fault free hiT 7070 ring

rerouted connection in RM

2-wire handset

connection interrupted due to fiber break

fiber break

connection

Ring manager (RM) function

OH/EOW

hiT 7070

OH/EOW

hit7070

OH/EOW

OH/EOW

hiT 7070

hiT7070

RM function in a disturbed hiT 7070 ringRM function in a disturbed hiT 7070 ring

Fig. 29 Ring manager function in a disturbed hiT 7070 ring


45/63



45

4.3.2 EOW configuration

To configure the EOW functionality the user needs to program the feature in thefollowing order:

Activate EOW

Assign Telephone Nr. to 2-wire handset

Connect/disconnect 4-wire E&M interface to EOW Conference

Connect E1/E2 OH byte(s) to EOWC as necessary

Optionally in SDH ring configuration connect RM to E1/E2 OH byte

TIPThe OHM module needs to be installed on the SCOH card.

Function: Activate EOW

Step Name of the Window Used Menu or Command Remarks

1 "Module View" Window Select (RMB) SCOH modulesymbol. From open menu select"Configuration > Card"

"SCOH Config"Window opens.

2 "SCOH Config" Window Set the "EOW Active"checkmark to "ON"

3 "SCOH Config" Window Confirm selection with the"Apply" button.

Function: Configure OH functions


1 "Module View" Window Select (RMB) NE functionalsymbol. From open menu select"Configuration > OverheadFunctions"

"NE - OverheadFunctionsConfig" Windowopens.

2 "NE - Overhead

Functions Config"

Set the three digit "Telephone

Number" as required

Telephone Nr.

for 2-wirehandset

3 "NE - OverheadFunctions Config"

Connect/disconnect 4-wire E&Minterface to EOWC as required.

4 "NE - OverheadFunctions Config"

Confirm selection with the"Apply" button.


46/63


TR3272EU00TR_0302

2003 Siemens AG

46

1

2

3

Fig. 30 EOW Active configuration

1

2

4

3

Fig. 31 Configure Overhead Functions


47/63



47

Function: Connect E1/E2 OH byte(s) to EOW Conference (EOWC)


1 "Module View" Window Select (RMB) SCOH modulesymbol. From open menu select"Configuration > OH Cross-connections"

"Overhead Crossconnection"Window opens.

2 "Overhead Crossconnection" Window

Select "STM-N E1/E2" OH byteyou want to connect and choose"Set as TP_A"


Select "EOW Conf" and choose"Set as TP_B"

4 "Overhead Cross

connection" Window

Set the cross-connection with the

"Connect" button.


For additional connections to theEOWC repeat steps 2 up to 4.

Function: Connect E1/E2 OH byte(s) to Ring manager (RM)


1 "Module View" Window Select (RMB) SCOH modulesymbol. From open menu select"Configuration > OH Cross-

connections"

"Overhead Crossconnection"Window opens.


Select "EOW Ring" and choose"Set as TP_A"


Select "STM-N E1/E2" OH byteyou want to connect and choose"Set as TP_B"


Set the cross-connection with the"Connect" button.

TIPIf you want to get a list of existing OH Cross-connections, select the "OH CC List"tab in the "Overhead Cross connection" Window (see Fig. 35).


48/63


49/63


50/63


TR3272EU00TR_0302

2003 Siemens AG

50

5 Exercises

Fig. 36


51/63



51


52/63


TR3272EU00TR_0302

2003 Siemens AG

52

Exercise 1

Title: MCF functions

Objectives: The participant shall be able to:

display and configure MCF parameters

Pre-requisite: Pre-read chapter "MCF configuration"

WARNINGThe following exercises will require active TNMS Core Client session.

Task 1

Ask your instructor for the name of your team (e.g. student01), IP address of theTNMS Core Main server (e.g. 10.10.72.190), name and the type of the NE which willbe use for the exercises (e.g. NE name: Muenchen; NE type: hiT 7070 DC) andwrite it down in the fields bellow:

I am working with the team: student _ _

IP address of TNMS Core: __ . __ . __ . __

Type of the NE: ___________________

Name of the NE: ____________________

Fig. 37


53/63



53

Start up the TNMS Core client SW and login to the TNMS Core.

Start up the Element Manager SW to open details view of the NE assigned to yourteam.

Open the "Message Communication Function" window and check the MCFsettings of the NE. Write down the MCF parameters of the NE in the table bellow.

Fill in the following table

NSAP AddressNE

Name

NE

Type Area Part SID Part

MAC

Address

Routing

Principle

Task 2

Using the data in the drawing below configure the MCF parameters for the NEassigned to your team.

WARNINGFor the parameters, which are not applicable, leave the default settings as they

are.

From the instructor PC (use a projector) check the MCF settings have beenconfigured for all network elements.

Fill in the following table

NE Name Stack Parameters DCC Parameters

6. Comply 7. Comply

8. Comply 9. Comply

10. Comply 11. Comply




54/63


TR3272EU00TR_0302

2003 Siemens AG

54

STM1

6

STM 16

STM1

6

STM 1 STM 1

STM 1

102#1

102

#3

102#1

102

#3

304#1304#1

303

#1

304

#1

303

#1

hiT 7070 SC

Nuernbergor Mainz

hiT 7070 SC

Ulm or Essen

hiT 7070 DC

Muenchen or Dortmund

hiT 7050 FP1

Augsburg or

Paderborn

hiT 7050 FP1

Erdingor

Giessen

Stack ParametersRouting Principle -> Level 1 IS

DCC ParametersPort Type #1 -> DCCMPort #1 -> 303 I FS2G5.01

Interface Type -> User

Port Type #2 -> DCCM

Port #2 -> 304 I FS2G5.01Interface Type -> Network

Student01

Student04

Student03

Student02


DCC ParametersPort Type #1 -> DCCMPort #1 -> 303 I FS2G5.01


Port Type #2 -> DCCMPort #2 -> 304 I FS2G5.01Interface Type -> Network


DCC ParametersPort Type #1 -> DCCM

Port #1 -> 102 O155-4.01Interface Type -> Network


Port #2 -> 102 O155-4.03Interface Type -> User


DCC ParametersPort Type #1 -> DCCMPort #1 -> 102 O155-4.01Interface Type -> User


Port #2 -> 102 O155-4.03Interface Type -> Network

TNMS CT

Server

Q ST

102

#1

102

#1

109#1

109#2

101

#1


DCC Parameters

Port Type #1 -> DCCMPort #1 -> 101 IFS2G5.01


Port Type #2 -> DCCMPort #2 -> 102 IFS2G5.01Interface Type -> Network

DCC ParametersPort Type #3 -> DCCMPort #3 -> 109 IFO155M.01

Interface Type -> Network

Port Type #4 -> DCCMPort #4 -> 109 IFO155M.02Interface Type -> User

Fig. 38 DCN setup

In the laboratory connect Gateway network elements (Muenchen or Dortmund) to thelocal TNMS CT via Q3 interface and disconnect all other NE's from the LAN (if theyare connected).

To prove the functionality of the DCN network deactivate and then activate againconnection to the NE's from "DCN Management" window of the TNMS CT. Login tothe network elements and perform some simple operations (e.g. request alarm data).


55/63


56/63


TR3272EU00TR_0302

2003 Siemens AG

56

Exercise 2

Title: EOW


configure EOW function

Pre-requisite: Pre-read chapter "EOW configuration"

WARNINGThe following exercises will require active TNMS Core Client session.

Task 1

Ask your instructor for the name of your team (e.g. student01), IP address of theTNMS Core Main server (e.g. 10.10.72.190), name and the type of the NE which willbe use for the exercises (e.g. NE name: Muenchen; NE type: hiT 7070 DC) andwrite it down in the fields bellow:

I am working with the team: student _ _

IP address of TNMS Core: __ . __ . __ . __

Type of the NE: ___________________

Name of the NE: ____________________

Fig. 41


57/63


58/63


TR3272EU00TR_0302

2003 Siemens AG

58

STM16

STM 16

STM16

EOW Plan (hiT 70xx Row 3)

hiT 7070 SC

Mainz

hiT 7070 SC

Mainz

304

#1

304

#1

303

#1

hiT 7070 DC

Dortmund

hiT 7070 DC

Dortmund

102

#1

102

#1

101

#1

hiT 7070 SC

Essen

hiT 7070 SCEssen

304#1

303

#1

Handset Tel. Nr.: 313 Handset Tel. Nr.: 312

Handset Tel. Nr.: 311

TP A TP B1-304 EOW Conf

IFQ2G5.01

MSOH 9.7 (E2)

TP A TP B

1-303 EOW Conf

IFQ2G5.01MSOH 9.7 (E2)

TP A TP B

1-101 EOW Conf

IFQ2G5.01

MSOH 9.7 (E2)

TP A TP B

1-102 EOW Conf

IFQ2G5.01

MSOH 9.7 (E2)

TP A TP B1-303 EOW Conf

IFQ2G5.01

MSOH 9.7 (E2)

TP A TP B

EOW Ring 1-304

IFQ2G5.01MSOH 9.7 (E2)

Fig. 42 EOW Plan (hiT 70xx Row 3)

STM16

STM 16

STM16

EOW Plan (hiT 70xx Row 8)

hiT 7070 SC

Nuernberg

hiT 7070 SC

Nuernberg

304

#1

304

#1

303

#1

hiT 7070 DC

Muenchen

hiT 7070 DC

Muenchen

102#1

102

#1

101

#1

hiT 7070 SC

Ulm

hiT 7070 SCUlm

304

#1

303

#1

Handset Tel. Nr.: 813 Handset Tel. Nr.: 812

Handset Tel. Nr.: 811

TP A TP B

1-304 EOW ConfIFQ2G5.01

MSOH 9.7 (E2)

TP A TP B

1-303 EOW Conf

IFQ2G5.01

MSOH 9.7 (E2)

TP A TP B

1-101 EOW Conf

IFQ2G5.01

MSOH 9.7 (E2)

TP A TP B

1-102 EOW Conf

IFQ2G5.01

MSOH 9.7 (E2)

TP A TP B

1-303 EOW ConfIFQ2G5.01

MSOH 9.7 (E2)

TP A TP B

EOW Ring 1-304

IFQ2G5.01

MSOH 9.7 (E2)

Fig. 43 EOW Plan (hiT 70xx Row8)


59/63


60/63


TR3272EU00TR_0302

2003 Siemens AG

60

6 Solution

Fig. 46


61/63



61


62/63


TR3272EU00TR_0302

2003 Siemens AG

62

Solution

Title: MCF functions


display and configure MCF parameters

Pre-requisite: Pre-read chapter "MCF configuration"

(No solution).


63/63


08 Tr3272eu00tr 0302 Mcf Configuration

Documents

Transcript of 08 Tr3272eu00tr 0302 Mcf Configuration