03802 data com.pdf

Tigris AXE Integration

< datacom training >

A developing your team’s skills

Tigris AXE Integration

Copyright © 1999, Telefonaktiebolaget LM Ericsson. All rights reserved.

All information contained in this document is the sole property of Telefonaktiebolaget LM Ericsson and is protected under copyright law. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage retrieval system, or translated into another language, without prior written consent of Telefonaktiebolaget LM Ericsson - Datacom Networks & IP Services, Stockholm, Sweden.

The information in this document is subject to change without notice.

Ericsson shall not be liable for inadvertent and unauthorized disclosure of information and errors contained herein nor for incidental or consequential damages in connection with the furnishing or use of this information. Ericsson makes no warranty of any kind with regard to this information, including, but not limited to, the implied warranties of fitness for a particular purpose.

First release, October 1999LZU 102 335 R1A

Table of Contents Tigris AXE Integration

.1-1

-1

18

20

-1

-

-20

Table of Contents1. Welcome ......................................................................

Introduction........................................................................................................................ 1-2

Course Prerequisites.......................................................................................................... 1-8

Course Materials................................................................................................................ 1-10

Course Objectives .............................................................................................................. 1-12

Course Agenda ................................................................................................................... 1-14

2. Introduction .................................................................2Tigris in the Narrowband World ..................................................................................... 2-2

PRA Integration................................................................................................................. 2-8

Digital Link Type2 (DL2) Integration ............................................................................. 2-12

Dial-Up Internet Access via DL2...................................................................................... 2-

Direct Access to the Internet in GSM .............................................................................. 2-

Self Test............................................................................................................................... 2-22

3. Tigris AXE/IAS Configuration .....................................3DL2 Integration..................................................................................................................3-2

DL2 Settings on Tigris....................................................................................................... 3-8

PRA Configuration ............................................................................................................ 3-10

PRA Settings on Tigris ...................................................................................................... 316

Trap Messages and Alarms............................................................................................... 3

Self Test............................................................................................................................... 3-26

LZU 102 335 R1A© Ericsson Telecom AB 1999

i

Tigris AXE Integration Table of Contents


ii

Chapter 1: Welcome Tigris AXE Integration

C H A P T E R

1 Welcome

Chapter Objectives

� Introduction

� Logistics� Ericsson Datacom Certification Programme

� Course Prerequisites

� Course Materials� Course Objectives

� Course Agenda


1 - 1

Notes:

Tigris AXE Integration Chapter 1: Welcome

Introduction

Name, Company and Location

Instructor’s name, the company the instructor works for and where.

Job Title and Responsibilities

Instructor’s job title and responsibilities associated with that job

Related Work Experience

What is the instructor’s background in this area, and related areas?

Course Expectations

What are your expectations of the course? What do you expect to learn, and what do you expect to be able to do with the new knowledge?


1 - 2


Figure 1.1

Introduction

�Name, Company and Location

�Job Title and Responsibilities

�Related Work Experience

�Course Expectations


1 - 3

Notes:


Logistics

Schedule: Class and Break Times

When you can expect to start and end class, and the duration, time and frequency of breaks.

Meals

Where you can take a meal.

Phones

What phones you can use, and when you can use them.

E-mail Connections

Where you can find computers to connect to your e-mail, and when you can use them.

Messages

To whom you should have messages directed, and when and how they will be delivered to you.

Washrooms

Where you can find the washrooms.

Smoking Facilities

Where you can find the smoking area, and when you can use it.

Emergency Procedures

Where to go in case of an emergency.

Transportation and Parking

Information on taxi companies, buses and parking facilities.


1 - 4


Figure 1.2

Logistics

�Schedule: Class & Break Times

�Meals

�Phones

�E-mail Connections

�Messages

�Restrooms

�Smoking Facilities

�Emergency Procedures

�Transportation and Parking


1 - 5

Notes:


Ericsson Datacom Certification Programme

The first release of the Ericsson Datacom Certification Programme includes three certification tracks (see figure 1.3)

� Access (based on Tigris MultiService Access Platform)

� IP Core (based on AXI 520 Gigarouter)

� Multiservice (based on AXD 301 IP&ATM Switch)

As well as the product related certification, as specified above, the programme also contains general technology certification tracks, not specifically associated with any product. In order to obtain a certificate, the candidate has to pass one or more exams (depending on the certification level).

Each certification track is divided into the following certification levels:

� Ericsson Datacom Technician (E1)

� Ericsson Datacom Technician Plus (E1 plus)� Ericsson Datacom Engineer (E2)

� Ericsson Datacom Engineer Plus (E2 plus)

Extensive and carefully designed courses will prepare students for subsequent certification tests.

E1 and E1 plus levels are targeted to those individuals responsible for installation and maintenance of equipment. The E1 certification level is the foundation for each of the certification tracks. To become E1 certified, the candidate has to successfully pass the Ericsson Datacom Technician Exam.

E1 plus certification, on the other hand, is specific to each certification track. To become E1 plus certified, the candidate has to fulfil the requirements for E1, then pass one Installation & Maintenance test from the chosen certification track (e.g. Tigris Installation & Maintenance Exam in the Access track).

E2 and E2 plus levels are targeted to those individuals responsible for support and implementation. Similar to the E1 level, E2 certification is common across all certification tracks, and tests the general competence in datacom technologies. To obtain an E2 certificate, the successful candidate has to be E1 certified, and pass all general technology exams.

E2 plus certification, like E1 plus certification, is specific to each certification track (i.e. E2 plus Multiservice). To obtain an E2 plus certification in one track, the candidate has to be certified at the E2 level, the E1 plus level from the certification track in question and pass one additional product related exam from the chosen certification track (e.g. AXD 301 Advanced Exam).

Exam registration

Testing is available through an independent testing centre network, managed by Virtual University Enterprises world-wide, found at www.vue.com.


1 - 6


Figure 1.3

E 2 – Ericsson Datacom Engineer

E 1 – Ericsson Datacom Technician

��

E 2plus Multiservice

E 1plus Multiservice

��

E 2plus Access

E 1plus Access

� ��

E 2plus IP Core

E 1plus IP Core

Ericsson Datacom Certification Programme


1 - 7

Notes:


Course Prerequisites

The student should have attended the Tigris/IAS - Operation & Configuration (LZU 102 333), AXE10 System Survey and AXE10 Testing 1 courses or have equivalent knowledge.


1 - 8


Figure 1.4

Course Prerequisites

� The student should have attended the Tigris/IAS -Operation & Configuration (LZU 102 333), AXE10 SystemSurvey and AXE10 Testing 1 courses or have equivalentknowledge.


1 - 9

Notes:


Course Materials

Course Manual

The course manual contains information in the form of text and graphics, that will be covered during the course. The manual has been designed with ample room for writing notes.

Lab Manual

The lab manual contains the exercises that will be completed during the course.

Evaluation Form

Upon the completion of the class, please take a moment to fill out the course evaluation form. Your answers and comments will be used to make improvements where necessary.

Reference Material

The instructor may provide additional reference material to compliment the course material.


1 - 10


Figure 1.5

Course Materials

�Course Manual

�Lab Manual

�Evaluation Form

�Reference Manual


1 - 11

Notes:


Course Objectives

The overall course objective is:

� To provide you with instruction specific to the integration of the Tigris/IAS with the Ericsson AXE 10 (LOCAL 6, 7) over PRA and DL2.


1 - 12


Figure 1.6

Course Objectives

The overall course objective is:

� To provide you with instruction specific to the integration of the Tigris/IAS with the Ericsson AXE 10 (LOCAL 6, 7) over PRA and DL2.


1 - 13

Notes:


Course Agenda

The following tables outline the course agenda:

Chapter Day Duration

Chapter 1 - Welcome 1 15 mins

Chapter 2 - Introduction 1 30 mins

Chapter 3 - Tigris AXE/IAS Configuration 1 30 mins

Exercise Day Duration

Exercise 1 - Test Configuration for Remote Access 1 1hr 30 mins

Exercise 2 - DL2 Configuration Exercise 1 1hr 30 mins

Exercise 3 - Tigris Configuration and Test of DL2 and PRA

1 3hrs


1 - 14


Figure 1.7

Course Agenda

Chapter Day Duration

Chapter 1 - Welcome 1 15 mins

Chapter 2 - Introduction 1 30 mins

Chapter 3 - Tigris AXE/IAS Configuration 1 30 mins

Exercise 1 - Test Configuration for Remote Access 1 1 hr 30 mins

Exercise 2 - DL2 Configuration Exercise 1 1 hr 30 mins

Exercise 3 - Tigris Configuration and Test of DL2 and PRA 1 3 hrs


1 - 15

Notes:



1 - 16

Chapter 2: Introduction Tigris AXE Integration

C H A P T E R

2 Introduction

Chapter ObjectivesAt the end of this chapter you will be able to:

� Understand the reasons for, and the benefits of, Tigris/AXE integration

� Understand how Tigris is Implemented in GSM

� Understand the make up of the subsystems required for PRA and DL2 integration

� Describe the call path for dial-up access


2 - 1

Notes:

Tigris AXE Integration Chapter 2: Introduction

Tigris in the Narrowband World

General The most common application for the Tigris Access Server is as a narrowband gateway into a broadband IP network. The primary function of Tigris is to convert modem, fax, ISDN data or voice into IP packets.

Tigris is connected via E1 or T1 circuits to a public exchange or central office where it routes incoming traffic through the time division multiplexing (TDM) backplane to Digital Signal Processors (DSP) and converts the traffic to packets and IP signals. This application shares a common platform with similar products providing a standards-based mechanism for connection to any type of public exchange. Although this provides an easy mechanism for the service provider there are inbuilt weaknesses. The biggest of these is the traffic load increase on the public exchanges which are set up for calls that have high costs but have short call-holding times.

As the data world is characterised by high call-holding times and low call costs there is a conflict of interests when we use traditional networks for data transmission. This conflict is not always under the control of the service providers as they are not usually one and the same company as the carrier, that is, the company operating the public exchange.

In general the consequences of using traditional networks for data transmission are network congestion and increased network size for little or no increase in income. Other concerns with this model are:

� The costs of E1/T1 ISDN circuits� The impact of increased circuit usage on exchange control logic� The operational and maintenance aspects of this additional new

equipment

The Ericsson approach to solving these problems is to integrate Tigris into the AXE/Mobile switching Services Centre (MSC). This is achieved by connecting the Tigris directly into the group switch of the AXE/MSC with a specially developed DL2 interface.


2 - 2


Figure 2.1

Internet Access in Traditional Networks

Mobile

ISP

CorporateNetwork

SmallOfficeHomeOffice

MobileUser

Fixed


2 - 3

Notes:


Tigris/AXE Integration

Integrated Access System

The Integrated Access System (IAS) is a product developed by Ericsson. The IAS offers an array of features ideal for operators and Internet Service Providers.

The IAS solution is a robust, scalable platform which can handle dial-up GSM, PSTN, ISDN as well as leased lines, X.25 and Frame Relay access upon which fixed or mobile operators or large ISPs can build a diverse range of services. These services can be delivered uniformly over a wide range of fixed or mobile access methods.

IAS in GSM The Internet Access System consists of three main parts:

� The MSC hardware� The MSC Software� Tigris

The IAS can also be used for dial-up ISDN and PSTN users. Tigris is fully compatible with other vendors’ MSCs. However when Tigris is used with other vendors MSCs, Tigris is not integrated into the MSC and this is not an IAS solution. An IAS solution envisages Tigris integrated into the MSC.

MSC Hardware

The MSC internal, proprietary Digital Link type 2 (DL2) interface is used to connect Tigris to the MSC group switch (GS). The Tigris multi-DL2 interface card connects to 16 DL2 interfaces in the GS.

The DL2 interfaces between the GS and Tigris are used entirely for dial-up GSM/ISDN/PSTN connections. Signalling information to and from the access servers is passed over an Ethernet connection between the Signalling Terminal for Open Communications (STOC) on the AXE side and the Ethernet interface on the Tigris control card. One STOC is sufficient to cater for signalling requirements of 32 AXC Tigris Access Servers.

AXE Software To implement IAS functionality in AXE, two new software blocks, Internet Access Bothway Trunk (IABT) and Internet Access Exchange Terminal (IAET) have been added in projects GSM R7 and Local 6. The function of these software blocks will be covered in more detail later in this course.

Tigris Platforms

There are three Tigris platforms, 3-slot, 7-slot, and 11-slot. The 7-slot and 11- slot servers are typically used for integration into the AXE. Tigris, has a nineteen inch chassis and fits into the AXE BYB501 cabinet. Tigris can also be connected to older BYB202 cabinets. There is a separate suite of cables for BYB202 connection.

IAS in Fixed Applications

In fixed networks like ISDN or PSTN using Local 6 software, Tigris can also be configured for primary rate access (PRA) using the E1/T1 interface card and the PRA equipment in the AXE Remote Subscriber Stage (RSS).


2 - 4


Figure 2.2

MobileFixed

IAS

TIGRIS

INTERNET

Integrated Access System

IP Networks

Fixed Hardware andSoftware


2 - 5

Notes:


End-User and Operator Benefits

Key Benefits The integration of Tigris into AXE has benefits for both the end-user and the operator.

End-User Benefits

The end-user in this configuration experiences faster call set-up times coupled with support for all modem types from V.34 standard to V.90 standard.

Other benefits include:

� Secure access to a use, corporate Local Area Network (LAN) for the Small Office Home Office or home worker environments.

� Decentralized access points in the telecom network of exchanges offer lower cost calls. Since the calls are terminated very early in the network, the charge is that of a local call.

Operator Benefits

The IAS enables the MSC to be directly connected to the Internet. This is called Internet Direct Access, allowing data calls to be terminated within the GSM network and allowing operators to build up a TCP/IP backbone. This support of dial-up IP connections opens up many opportunities for operators to offer data applications and services targeted specifically at the mobile user.

Other benefits include:

� New business opportunities, as the operator can build a diverse range of services.

� The operator's total transmission costs will be lower because early termination of the data traffic means that there are no inter-network costs.

� The DL2 interface eliminates the need for PRA and increases modem density per shelf.

� The MSC gains Remote Access Server (RAS) functionality as one AXE/MSC can support up to 32 Tigris. This means that there need only be a small number of access points throughout the network.

� Tigris provides superior modem performance delivering a scalable, high performance dial-up solution.

� Virtual Port Service Manager (VPSM) allows operators to create multi service profiles for customers with varying quality of service (QoS).

� Improved fault tolerance when routing calls.� Common operations and maintenance (O&M) interface.� As traffic is diverted early from the trunk network, there is more efficient

use made of existing infrastructure.� Tigris supports “hot replacement” of interface cards and fans thereby

reducing the amount of down-time for the system.� Virtual Port Service Manager (VPSM) is server-based software designed

to manage the access partitioning and Virtual Private Networking (VPN) capabilities of Tigris.


2 - 6


Figure 2.3

Benefits of the Integrated Access System

End-User:

• Faster Call Set-Up Times• Secure Access• Lower Costs

Operator:

• New Service Offerings• Lower Transmission Costs• DL2 eliminates need for PRA and Improves Port density• Virtual Private Network• RAS Functionality• Security


2 - 7

Notes:


PRA Integration

GAM The Generic Access Manager (GAM) is an AXE 10 platform for connecting different type of access, such as PRA access, to the subscriber switch in AXE.

The GAM platform is a set of central processor and regional processor software units, and hardware units. These software and hardware units allow the operator to connect, disconnect, maintain and configure exchange terminals (ET) and signalling channels towards an ST.

GAM defines a common terminology and common technical base in the Subscriber Switching Stage (SSS) for Pulse Code Modulation (PCM) access applications. Within GAM, an application consists of two parts:

� A GAM part that is identical for different applications� An application part that contains the application-specific parts

For different applications, different software will be loaded in the extension module regional processor type 4 (EMRP4) and GAM-Regional Processor (GAM-RP). All these applications are supported by the same hardware.

GAM offers high reliability and D-channel traffic capability. In the case of the regional processor devices (RPD), the layer two protocol LAP-D is terminated in the transceiver-handling board via the group switch. LAP-D is terminated in the processor board for the regional processor group (RPG).


2 - 8


Figure 2.4

Different Applications on GAM

Primary Rate Access Integrated Access System V.5.2 Signalling

Generic Access Manager


2 - 9

Notes:


PRA Integration (Contd)

GAM Hardware Interface

The same Line Switch Module (LSM) and GAM-RP could be used by any access application. The basic configuration includes an access part, the group switch (GS), and a pool of signalling terminals on regional processor devices (RPD).

Any application is connected to GAM through a standardized interface. The application itself defines its set of software blocks necessary to perform that function. These are loaded in the LSM and GAM-RP. The GAM platform provides different services to the access application.

In the diagram Tigris is connected to the Remote Subscriber Stage (RSS) by the Exchange Terminal Card for PRA (ETCP) in the LSM. Calls terminating in the RSS are switched via the time switch (TS) without going to the parent exchange for processing. All other calls are switched to the Exchange Terminal Board (ETB) which connects to the GS in the parent exchange via the ETC.

Signalling for voice calls is handled by the combination of signalling terminal on the remote end (STR) and the signalling terminal at the central site (STC). The EMRP is the controlling device for the LSM.

Signalling for data calls for Tigris is handled in the parent exchange where layer two and three signals (LAP-D and DSS1 respectively) are processed by a Signalling Terminal called a transceiver handler board (TRH). An RPD or RPG controls the TRH, and signals are transmitted transparently through the GS to the RPD/RPG.

In BYB501 exchanges the Exchange Terminal Card (ETC), Signalling Terminal Central (STC) and TRH are implemented in the Generic Device Magazine (GDM).


2 - 10


Figure 2.5

Tigris on the GAM Platform

GroupSwitch

TRH

ETC

CP

STC RP

EMRP3

TS ETB

STR

Tigris

E1/T1MAU

Remote Subscriber Stage

ETCP

Local Exchange

RPD/RPG


2 - 11

Notes:


Digital Link Type2 (DL2) Integration

DL2 Hardware Configuration

Digital Link Type2 (DL2) is an Ericsson proprietary interface. It is used to connect Tigris directly into the AXE group switch to eliminate the need for PRA circuitry.

On the Tigris control card there are two Ethernet interfaces. The media attachment unit (MAU) is the interconnect point between the twisted pair cable from the signalling terminal for open communications (STOC) and the control card. The MAU is attached to the chassis at the rear via a champ connector in the corresponding position as the control card. We only need to use the MAU in the 3-slot and 7-slot.

At the AXE end of a STOC is the TCP/IP interface. The DL2 interface consists of 32 channels on a 2 Mbit/s link. Tigris has four DL2 interfaces giving 512 subscriber circuits per interface card.

The DL2 interface card is connected using the four cables as shown in the diagram. Cables 1 and 3 are connected to time switch module (TSM) A, and cables 2 and 4 are connected to TSM B.

Note: In AXE the GS has an A-plane and B-plane for switching calls through the exchange. These are used for redundancy to ensure that there are very few calls lost or not made.

The hubs to which the Ethernet cables are connected are used to allow connections to the Hyper-Text Transfer Protocol (HTTP) server resident on Tigris and for initiating Telnet sessions. Only two Telnet sessions can be running simultaneously.

Note that the two Ethernet interfaces are connected to redundant STOCs. Should the executive STOC fail then all the calls in progress whose signalling is controlled by this STOC are lost but signalling for all new calls will be handled by the stand-by STOC.


2 - 12


Figure 2.6

Tigris and the DL2 Interface

TigrisControlCard

DL2

WAN

STOC

STOC

GS

TSM B

TSM A

EthernetTCP/IP

DL2

MAU

HUB

1234

AXE


2 - 13

Notes:


DL2 Integration

AXE Software Blocks for IAS

The following subsystems in AXE are involved in traffic handling, maintenance and management for the Tigris over the DL2 interface.

IAS The software for the DL2 interface is mainly implemented in Internet Access Subsystem (IAS).

OCS Open Communication Subsystem (OCS) is used as a platform for communication between the AXE and remote hosts connected to a TCP/IP-based network. The subsystem consists of central, regional software (OCITSR) and hardware (the STOC).

OCS has two main function blocks:

� OCITS (Open Communication Internet Transport Service), The function block consists of central as well as regional software, and provides a user interface for applications in the CP or RPD to use TCP/IP transport services. The TCP/IP transport service is then used to reach remote hosts, that is, to communicate with the protocol software in Tigris. OCITS informs IABT if the TCP/IP connection is lost.

� OCADM (Administration of Open Communication Internet Transport Service), This function block is used in the administration of OCITS. Command and printout handling is partly handled through the Database Subsystem (DBS), for example the network addresses and STOC IP-addresses defined in DBS by DBS commands.

TCS The Traffic Control Subsystem (TCS) is used to route the data calls to and from Tigris by means of B-number analysis.

OMS The Operation & Maintenance Subsystem (OMS) is used for administration and supervision of routes and devices in IABT and signalling network terminal (SNT).

NMS The Network Management Subsystem (NMS) includes information and control functions for network management.

GSS The Group Switching Subsystem (GSS) performs switching between time-multiplexed buses. The GSS connects a channel (time slot) in one PCM system to a channel in another PCM system.


2 - 14


Figure 2.7

Software Overview For IAS

Protocol Software

TCS

OCSNMS

GSS

Tigris

OCS

DBSFor STOC

IABT

IAET

DL2s Ethernet

AXE


2 - 15

Notes:


DL2 Integration (Contd)

The Software Blocks IABT and IAET

Call control is handled by blocks IABT and IAET via the OCITS block, which is part of OCS.

IABT The function block IABT is a block consisting of central software only. The rest of the AXE system identifies it as a typical BT block. It interfaces to TCS as a normal BT block.

IABT communicates with Tigris by means of a protocol, called Etheric 1.0, which runs on top of TCP/IP over Ethernet. This protocol is of the common channel type. This means that one signalling channel can handle thousands of data circuits. Ethernet is used as the physical medium and the Transport Control Protocol (TCP), implemented in OCITS, is used for the transfer of signalling information.

IABT implements the protocol and translates between the protocol and the AXE internal interfaces using software signals.

IABT controls the devices and routes in the DL2 interface. The devices will be automatically blocked on order from the IAET block if a DL2 link does not work. Devices will also be automatically blocked if the signalling connection to Tigris is lost. IABT also controls the Etheric protocol and administrates the IP addresses for the signalling destination. The signalling for the traffic handling and circuit maintenance time slot which is on the DL2 interface is adapted to the OCITS. The data to and from OCITS is sent and received in the form of messages like the Initial Address Messages (IAM) used in voice call set-up.

IAET The function block IAET handles administration and maintenance of SNT. It is implemented in central software only. It is required for the virtual SNT, where one Multi-DL2 interface card on the Tigris is represented by IAET as an SNT with sixteen switching network terminal points (SNTP). An SNTP is that point where an SNT connects to the GS via the DL2 link. Each DL2 interface carries 32 time slots that can be used for traffic.

The Multi-DL2 interface card is a virtual SNT that has no RP/EM control and has limited support for SNT supervision and monitoring. There is no communication between IAET and Tigris for SNT supervision and maintenance. Instead the DL2 link is continuously supervised by the GSS and IAET is informed by GSS if a fault is detected. The SNT is detected faulty and automatically blocked when all of its DL2 interfaces experience loss of synchronization. If at least one of its connected DL2 interfaces is synchronized, the SNT is considered operational.


2 - 16


Figure 2.8

Software Blocks in call Control for DL2

OCITS

TCS IABT

IAET

GSSTigrisSoftware

DL2

TCP/IP/Ethernet


2 - 17

Notes:


Dial-Up Internet Access via DL2

This example demonstrates how the hardware and software interworks for an outgoing call via the PSTN or ISDN for Internet Access.

1. The register, function block RE in the TCS orders the selection of an outgoing device based on the dialled number which is analysed using B-number analysis and route analysis where the block IABT and route are indicated.

2. RE orders GSS to set up a traffic path through the GS between the selected multiple position (MUP) for the junctor terminal channel to the MUP for the outgoing IABT channel.

3. RE delivers all the data required for the message to the IABT block. The data consists of:

� A-number� B-number� A-number category � An indicator as to whether it's a PSTN modem call or ISDN call

4. Block IABT assembles the message according to the Etheric protocol and sends it to the OCITS block with the correct Call Identity Circuit (CIC) and the IP address of the signalling destination, which is Tigris.

5. Block OCITS adds a TCP/IP header and sends the data package to the proper STOC for transmission.

6. The STOC sends the data package in the form of an IAM message over the Ethernet bus to Tigris where a connection is made over the DL2 interface based on the CIC.

7. Tigris performs analysis of the called number in the called number table and sends set-up information to the right ISP over a packet switched IP network such as Frame Relay or X.25.


2 - 18


Figure 2.9

Dial-up Internet Access via DL2

Tigris

RegisterBlock

GS

IABT OCITS

STOC

PCRSS

Local Exchange

GroupSwitch

IP Network

Hardware

Software

Traffic ControlSubsystem

Group SwitchSubsystem

Internet AccessSubsystem

Open CommunicationsSubsystem

1

2

3

4 5

6

7


2 - 19

Notes:


Direct Access to the Internet in GSM

Technical Description

The Direct Access to the Internet service is requested from the user’s Mobile Station by dialling a prefix for example,*37* before the B number. The prefix indicates a direct access call. The protocol requirement in the mobile terminal is Internet Protocol (IP) and Point-to-Point Protocol (PPP). This means that all dial-up TCP/IP based applications such as Web browsers, File Transfer Protocol (FTP), e-mail, and so on, are supported.

The inter-working function (IWF), that is, the GSM Inter-Working Unit (GIWU, or the Data Transmission Interworking unit (DTI) handles the direct access call as a normal asynchronous Non Transparent (NT) Unrestricted Digital Information (UDI) call. However, instead of routing the call to an ISDN network, it is routed to a Direct Access Node (DAN).

DAN includes one or more Tigris. The DAN can physically be included in the originating MSC/Visitor Location Register (VLR), in another MSC/VLR in the same Public Land Mobile Network (PLMN) or in an MSC/VLR of another PLMN. When a user roams to a foreign PLMN and wants to connect to a DAN in the home PLMN, the MSC/VLR in the foreign PLMN must also support the prefix method for identifying a direct access call. There must be some agreement between the PLMN operators and the ISPs involved. The IWF and Tigris must be contained in Ericsson nodes in order to support Direct Access.

The purpose of Tigris is to act as an access server, that is, it terminates the PPP protocol and concentrates the traffic over the packet switched IP network. The IP packets are forwarded out from Tigris using Ethernet encapsulation. Thus Tigris also acts as an IP concentrator, meaning that many incoming calls, each occupying one 64 kbit/s link, are multiplexed onto the Ethernet.

The Direct Access service also supports Layer Two Tunneling Protocol (L2TP) using a configuration in which the PPP packets from the end-user are tunneled to the external data network on an IP tunnel. Tunneling is used to create secure Virtual Private Networks (VPNs) using the public Internet infrastructure. When a High Speed Circuit Switched Data (HSCSD) is used in combination with Direct Access, there are no data rate restrictions caused by modem connections or rate adaptation. This means that the fixed network data rate is given by the number of time slots used (maximum 38.4 kbit/s, when using four timeslots, and 9.6 kbit/s channel coding).


2 - 20


Figure 2.10

Direct Access to the Internet

In ternet

DTI

TigrisTigris

MSC/DAN

Router

ISDN

MobileNetwork

MSC


2 - 21

Notes:


Self Test

1. What are the inherent weaknesses in using traditional voice networks for data transmission?

2. What is the difference between IAS and Tigris?

3. What is meant by “the MSC gains RAS functionality”?

4. What is the Generic Access Manager?

5. Where in AXE is the signalling handled for:

� A voice call� A data call

6. Why are there two STOCs connected to Tigris?

7. What is the function of the hub in the connection of Tigris to the AXE?

8. What is the function of the Open Communication Subsystem?

9. Briefly describe the Direct Access service in GSM.


2 - 22

Chapter 3: Tigris AXE/IAS Configuration Tigris AXE Integration

C H A P T E R

3 Tigris AXE/IAS Configuration

Chapter Objectives

After completing this chapter you will be able to:

� Interpret and use DL2 and PRA interface commands

� Verify AXE data transcripts and examine AXE settings for the relevant Tigris/AXE connection method

� Interpret alarms and Trap messages and suggest corrective actions


3 - 1

Notes:

Tigris AXE Integration Chapter 3: Tigris AXE/IAS Configuration

DL2 Integration

TCP Connection Management

Tigris is integrated into the AXE environment as a Signalling Network Terminal (SNT). Call set up and control occur over two Transport Control Protocol (TCP) connections, one for odd CICs and one for even CICs. Pulse Coded Modulation (PCM) encoded data is carried over 16 DL2 connections to Tigris.

Signalling for the DL2 interfaces operates over TCP/IP connections between Tigris and an AXE switch. Although the typical installation will maintain the TCP connections over an Ethernet, or pair of Ethernet between the Tigris and the AXE, the design and implementation of the signalling only takes account of the TCP connection/socket interface and makes no assumptions about the interconnect media.

The protocol which is run on these connections is Etheric. Etheric is a version of Number 7 signalling.Ethernet is used as the physical medium and TCP is used for the transfer of signalling information.

Each Ethernet connection between Tigris and the AXE forms a separate network. TCP runs on top of IP and, therefore, IP addresses are required on each interface between the STOC and Tigris. It is the use of an IP address and subnet mask that defines the individual networks.

The IP addresses used in this example are taken from Request For Comment (RFC) 1597, which defines a subset of IP address space that is reserved for private networks. Tigris and the STOC form their own private network(s) so the numbers shown here will work in an installation. Since the IP numbers used are reserved private addresses, they can never be advertised in a route table that will propagate to the public Internet.

The IP address contains two basic pieces of information:

� The network number � The host number

The identification of each part is done with a template, called a subnet mask. A subnet mask is a 32-bit number that corresponds bit-for-bit with the 32-bit IP address. For each bit set to 1 in the subnet mask, the corresponding bit position in the IP address is interpreted as part of the network address. For each bit set to 0 in the subnet mask, the corresponding bit position in the IP address is interpreted as part of the host address.

The implementation of Tigris in the MSC is identical to that for the DL2 interface in a fixed switch. Release 6 (R6) software is the minimum needed to implement the DL2 connection. R7 software is the minimum version of software needed to implement the PRA connection in the MSC.


3 - 2


Figure 3.1

TCP Connection Settings on Tigris

192.168.1.0255.255.255.0

Tigris

J7.1

J7.2

STOC

HUB

192.168.2.0255.255.255.0


3 - 3

Notes:



Network Configuration on Tigris

To configure the first Tigris Ethernet interface J7.1 with the IP address 192.168.1.1, issue the command:

add ip net ent 192.168.1.1 255.255.255.0 j7.1

Repeat the command for Ethernet port j7.2 with an address of 192.168.2.1 if a redundant Ethernet connection is to be made. Make the corresponding entries to the configuration on the AXE. This will place the STOC and the Tigris on the same IP network.

Save the configuration with the command:

set config save

Then verify the IP address just entered with the command:

display ip network table

AXE Configuration

The TCP connection(s) in AXE for the STOC is defined in the Database Subsystem (DBS) using different tables. To define the network 192.168.1.0 with subnet mask 255.255.255.0 and the host address for the STOC 192.168.1.2 in DBS the following command sequence is used:

Configure Network

Start a Database transaction

DBTRI;

Define the network configuration

DBTSI:TAB=OCSNETWORK,NETIPB1=192,NETIPB2= 168,NETIPB3=1,NETIPB4=0,NMASKB1=255, NMASKB2=255,NMASKB3=255,NMASKB4=0;

The different parameters in the command are described in the table description for table OCSNETWORK.

End the Database transaction

DBTRE:COM; (Commits the transaction and updates the table)

Define STOC Device Data

Start and end the transaction as above.

DBTSI:TAB=OCSSTOC,STOCID=0,STOCIP1=192, STOCIP2=168,STOCIP3=1,STOCIP4=2,NETIPB1= 192,NETIPB2=168,NETIPB3=1,NETIPB4=0,RPNUMB=57,EMNUMB=0;

NOTE: Parameters RPNUMB and EMNUMB are not applicable when OCITS version R1A14 is being used.


3 - 4


Figure 3.2

IP Addresses for Tigris and AXE

TigrisJ7.1

J7.2

STOC

192.168.1.1

192.168.1.2

Network 192.168.1.0


3 - 5

Notes:



DL2 Settings on AXE

The following command set describes the steps necessary to connect the DL2 interface to AXE.

Definition of a Switching Network Terminal (SNT) that is Tigris

NTCOI:SNT=IAET-0,SNTV=1,SNTP=TSM-4-0&&-15;

Connection of devices to SNT

EXDUI:DEV=IABT-0&&-511;

Deblocking of the SNT

NTBLE:SNT=IAET-0;

Definition of route data for the traffic route between AXE and Tigris

EXROI:R=IABT1O&IABT1I,FNC=3,DETY=IABT;

FNC=3 means a route for bothway traffic

Definition of pointer to current destination

EXRBC:R=IABT1O,MIS5=1;

MIS5 points out the right signalling destination, which isTigris. The maximum value for mis5 is equal to the number of Tigris's in the network.

Definition of the IP addresses for the routes

EXRBC:R=IABT1O,MIS1=H'C0A8,MIS2=H'0101;

MIS1 is the IP address of Tigris, byte3 & byte2 i.e. 192 and 168 in Hex.

MIS2 is the IP address of Tigris, byte1 & byte0 i.e. 1 and 1 in Hex.

Here we have defined the IP address of Tigris as 192.168.1.1. For a second redundant Ethernet connection the command has to be repeated and the parameters MIS3 and MIS4 are used to define the IP address.

Definition of the Circuit Identifier Code (CIC) and connection of devices to the routes

EXDRI:R=IABT1O&IABT1I,DEV=IABT-0,MISC1=0;

EXDRI:R=IABT1O&IABT1I,DEV=IABT-1&&-31;

EXDRI:R=IABT1O&IABT1I,DEV=IABT-32,MISC1=32;

EXDRI:R=IABT1O&IABT1I,DEV=IABT-33&&-63;

MISC1 is used to set the CIC value for the trunk devices in AXE. The value given is that of the first device of the current DL2 interface, that is, device 0, 32 and so on. CICs are used to identify the time slots on the DL2 interface.


3 - 6


Figure 3.3

GSGS

IAS

STOC

Ethernet

16

IP-address STOC:192.168.1.2

IP-address IAS:192.168.1.1

Network address:192.168.1.0

SNT:IAET-0RP

TSM:TSM-A-4Traffic Routes:IABT1O&IABT1I

SNTP’s:TSM-4-0&&-15

Connecting the Access Interface - DL2


3 - 7

Notes:


DL2 Settings on Tigris

For DL2 switching to succeed Tigris must be configured with CIC values that match the CIC values on the AXE for the DL2 connections. The first time slot on the first interface on the first DL2 installed is assigned the specified value. All subsequent time slots on that interface, and all other interfaces installed are assigned sequentially incrementing values from the base CIC.

By default the CIC settings on Tigris should match the settings in the route definitions given by the AXE command EXDRI. Begin by displaying the default values and determine circuit status using the commands:

display dl2 circuit table

display dl2 statistics

This table gives all the statistics for all the DL2 channels.

If necessary the CIC base can be changed with the command:

set dl2 cic base cic_base


3 - 8


Figure 3.4

DL2 Circuit Table

Tigris> disp dl2 cir ta

Port Timeslot CIC Status StateJ1.1 0 0 UNBLOCKED IDLEJ1.1 1 1 UNBLOCKED IDLEJ1.1 2 2 UNBLOCKED IDLEJ1.1 3 3 UNBLOCKED IDLEJ1.1 4 4 UNBLOCKED IDLEJ1.1 5 5 UNBLOCKED IDLEJ1.1 6 6 UNBLOCKED IDLEJ1.1 7 7 UNBLOCKED IDLEJ1.1 8 8 UNBLOCKED IDLE


3 - 9

Notes:


PRA Configuration

Connection of PRA

In the text below, the general procedure for definition of an LSM-PRA is described.

Connection of Signalling Terminal

Definition of RP to handle the control for the Transceiver Handler Board (TRHB)

EXRPI:RP=rp,TYPE=RPD1A;

Definition of regional software units. These are software units that control the hardware.

EXRUI:RP=rp,SUNAME=STGAMR;

EXRUI:RP=rp,SUNAME=DLPRAR;

EXRUI:RP=rp,SUNAME=MANPRAR;

EXRUI:RP=rp,SUNAME=MHPRAR;

Where SUNAME is the name of the software units for the RP.

Definition of equipment

EXEMI:RP=rp,EM=em,EQM=STGAM-0&&-31;

EXEMI:RP=rp,EM=em,EQM=DLPRA-0;

EXEMI:RP=rp,EM=em,EQM=MANPRA-0;

EXEMI:RP=rp,EM=em,EQM=MHPRA-0;

Connection of TRH to the group switch. This device handles the signalling for the PRA access

NTCOI:SNT=STGAM-0,SNTV=1,SNTP=sntp;

Connection of devices (timeslots) controlled by TRHB

EXDUI:DEV=STGAM-0&&-31;


3 - 10


Figure 3.5

Connection of Signalling Terminal(SNT) andRegional Processor(RP)

GS

Tigris

E1/T1MAU ETCP

TS ETB

LSM-PRA

RSS

ETC

TRHB

RPDRPSTC

STREMRP3

SNT=STGAM

RP


3 - 11

Notes:


PRA Configuration (Contd)

Definition of GAM SNT

Connection of Access Equipment in LSM PRA

Definition of EMRP in the EMG

EXEPI:EMG=emg,EM=em,TYPE=EMRP3,CONTROL=SINGLE;

Definition of the regional software in the EMRP. The command has to be repeated for each software unit that is to be loaded.

EXEUI:EMG=emg,EM=em,SUNAME=suname;

Definition of PRA equipment. The command has to be repeated for each software unit that is to be loaded.

EXEUI:EMG=emg,EM=em,SUNAME=suname;

Definition of PRA equipment. The command has to be repeated for each type of equipment that is to be connected.

EXEEI:EMG=emg,EM=em,EQM=eqm;

Definition of the switching network terminal ETCP. Tigris is an extension of the ETCP and therefore seen as a virtual SNT by AXE.

NTCOI:SNT=ETGAM-xx,SNTV=sntv;

Connect the primary rate accesses to the SNT which is Tigris

GNSAI:SNT=ETGAM-xx,ACCOWN=accown;

ACCOWN is the access owner type, that is, PRA, V5.1 etc.

Connection of digital path (DIP)

DTDII:DIP=xxETGAM,SNT=ETGAM-xx;

DIP transmission data

DTIDC:DIP=xxETGAM,CRC=0,QSUP=0;

Some deblocking commands for this exercise:

BLEEE:EMG=emg,EM=em;

NTBLE:SNT=ETGAM-xx;

DTBLE:DIP=xxETGAM;

BLODE:DEV=LIPRAE-xx&&yy;


3 - 12


Figure 3.6

Connection of Line Switch Module(LSM) in PRA

GS

Tigris

E1/T1MAU ETC

P

TS ETB

LSM-PRA

RSS

ETC

RPSTC

STREMRP3

TRHB

RPD

STGAM

RP Device

SNT=ETGAMxxDIP=xxETGAM

EMRP3


3 - 13

Notes:


PRA Configuration (Contd)

The Access Connection

At this stage in the exercise the access group and the D-channel are connected and the semi-permanent connection across the group switch is set-up.

A semi-permanent connection is a fixed programmed connection set up in the group switch. This connection is used as a secure path for channel 16 signalling.

GNACI:AG=ag,DEV=LIPRAE-xx;

The access group (AG) is a group of accesses of the same type, for example, PRA whose signalling channels are connected to the same signalling terminal and whose Layer 2 and Layer 3 protocol are handled by the RPD.

Each AG has a number, which is a logical number that refers to the AG and not to any physical hardware.

The connection between the AG and a physical signalling terminal is handled automatically by GAM. For each PRA, version 5 signalling (V5.1) application, there is a pool of signalling terminals, from which GAM fetches a signalling terminal. GAM connects the signalling terminal to an AG in order to handle traffic. Signalling terminals left in the pool are stand-by terminals which can be connected when the selected signalling terminal fails. Switchover from a faulty signalling terminal to a stand-by one in the same pool is done automatically by the system when a failure occurs.

The AG is created using the command GNACI. GNACI allows for load distribution over different signalling terminals so that each one can have a desirable load.

With command GNSPP, the hardware connection initiated by the system can be printed.

The use of access groups, number groups and hunting groups indicates to the AXE that there is a private branch exchange (PBX) to be connected to the AXE because there is one number defined with several accesses associated with it as would be found in an office situation. The following commands define how to configure a PBX with access groups, number groups and hunting groups.

IUPBI:PBX=pbx,SNB=snb,REFP=2;

IUPDI:PBX=pbx,DEV=LIPRAE-xx&&yy;

IUPHI:PBX=pbx,HG=2,DEV=LIPRAE-xx&&yy;

IUPHC:PBX=pbx,HT=1;

IUPHC:PBX=pbx,HG=2,HT=1;

IUPVI:PBX=pbx,DEV=LIPRAE-xx&&yy,ANO=700048,L=8;


3 - 14


Figure 3.7

PRA Interface Connection in AXE

GS

IAS-C

E1/T1MAU ETC

P

TS ETB

LSM-PRA


ETC

TRHB

RPDRPSTC

STREMRP3

SubscriberNumber

DIP=xxETGAM

DEV=LIPRAE-yy

SNT=ETGAM-xxRT DEV USED

BY GAM

SNT=STGAM-x

AG

CP


3 - 15

Notes:


PRA Settings on Tigris

Key Issues The following four key issues must be considered, when connecting Tigris to a PRA interface:

� The Source of Clocking� The Length of the Line� The Framing and Line Code� Signalling

Each item must be addressed prior to IAS-C PRA installation. To examine the default settings as well as specific alarm conditions for all interfaces, or a particular interface, issue the following command:

display ds1 interface table

or

display ds1 interface entry [phy_port_id]

The following entries are examples of various DS1 parameters and their associated settings:

� set ds1 interface framing

PORT_ID [PHYSICAL] the physical port is defined as Jx.y

FRAME_FORMAT is the type of error detection/correction to be used. CRC is the default value.

[ESF|D4|NOCRC|CRC|NOCRC_MF|CRC_MF]

� set ds1 interface line code


LINE_CODE [B8ZS|HDB3] bipolar 8 zero suppression (b8zs) is used for T1 lines and high-density bipolar 8 suppression is used on E1 lines.

� set ds1 interface clocking


CLOCK_SOURCE see network synchronization overleaf

[EXTERNAL|INTERNAL|NETSYNC]

� set ds1 in signalling


SIGNAL_MODE defines the use of channel associated or common channel signalling.

[NONE|RBS|CAS|CCS|NFAS]


3 - 16


Figure 3.8

PROMPT? display ds1 interface tab

Interface = J1.1 Framing = ESF Line Status = No AlarmsInterface ID = 0 Line Code = B8ZS Line Length = LONGTrunk Group = 0 Signaling = CCS Clocking = NETSYNCNumber Group = 0 Precedence = PRIMARY Transceiver = CSU2Loopback = NONE Circuit Name = NONE Type = NORMAL

Interface = J1.2 Framing = ESF Line Status = OOF,LOSInterface ID = 0 Line Code = B8ZS Line Length = SHORTTrunk Group = 0 Signaling = CCS Clocking = NETSYNCNumber Group = 0 Precedence = PRIMARY Transceiver = CSU2Loopback = NONE Circuit Name = NONE Type = NORMAL

An Example of the Interface Table Printout


3 - 17

Notes:


PRA Settings on Tigris (Contd)

Interface Alarms

The field, Line Status, in the ds1 interface table indicates specific alarms for that interface. Possible alarm conditions are:

� AIS - indicates a far end sending an alarm indication signal� AISX - indicates a near end sending an alarm indication signal� AIS16 - indicates an E1 TS16 alarm indication signal� LOMF - indicates a far end sending a TS 16 loss of multiframe� LOMFX - indicates a near-end sending a TS16 loss of multiframe� LOOP - indicates that a near-end loopback is activated� LOS - indicates a near-end loss of signal� NONE - indicates that there are no exceptional conditions or alarms� OOF - indicates a near-end out-of-frame alarm (red alarm)� RAI - indicates a far end sending an out-of-frame (yellow alarm)� OOFX - indicates a near end sending an out-of-frame� TEST - indicates that a near end is detecting a test code

Network Synchronization

Tigris uses a time division multiplexing bus to interconnect DS0s between interface cards. For the interconnection to work properly all interconnecting devices must be synchronized to the same clock source. The Network Synchronization feature handles this function. The clocking therefore should be set to NETSYNC for all T1/E1 interfaces.

NETSYNC makes a common clock available to all cards on the Tigris backplane. The source for this clock can be generated internally on a priority basis or derived from:

� T1/E1 � DL2 interface

The priority system allows for a primary source to have a hierarchy of secondary sources supported by automatic, non-interrupting switch-over. By default the Tigris will be properly configured to use the NETSYNC feature. In the factory default state the backplane clock will be derived from the first alarm free interface found in the interface table starting with J1.1. To check the NETSYNC table issue the command:

display network synchronization table

The first READY interface found in the table is J1.1 and it is being used as the NETSYNC clock as indicated by the CURRENT state:

Tigris> disp net sync ta

Source Port Priority Recovery Thresh Khz State Fails

EXTERNAL NONE DISABLED MANUAL 0 2048 READY 0

DERIVED J1.1 MEDIUM AUTOMATIC 0 2048 CURRENT 0


3 - 18


Figure 3.9

Interface Alarm Conditions

• AIS - indicates a far end sending an alarm indication signal

• AISX - indicates a near end sending an alarm indication signal

• LOOP - indicates that a near-end loopback is activated

• LOS - indicates a near-end loss of signal

• NONE - indicates that there are no exceptional conditions or alarms

• OOF - indicates a near-end out-of-frame alarm (red alarm)

• RAI - indicates a far end sending out-of-frame (yellow alarm)


3 - 19

Notes:


Trap Messages and Alarms

Trap Messages Trap messages are responses to events which occur within Tigris, for example, when interfaces are connected to, or disconnected from, the Tigris.

When the reset command is issued a Trap message is received by the Tigris console. The Trap time shows the Trap that was generated since the last system reset.

TIGRIS>

***TRAP from local agent at 20-Aug-1999 uptime 0 Days, 00:12:50

***Operator initiated reset......

Trap Log Tigris has the ability to store the Trap messages, which it generates in a log file. Information logged includes:

� The time of the Trap message� The level of the Trap message� The type of Trap message� The text string of the generated Trap message

The number of Trap messages which can be stored is limited by the size of the buffer used to record the messages and the amount of data provided in each Trap. An adjustable default buffer size of 4 bytes is used.

The Trap log remains intact on reset, but is lost on reload. The Trap log may be saved to the Flash file system into a file called TRAP.LOG. This file can be downloaded through TFTP for off-line analysis on systems that have full file- system support.


3 - 20


Figure 3.10

The Trap Log Table

Tigris> Display trap log table

Trap Time Trap Type Trap Data Summary0 Days, 00:00:07 ENTERPRISE Lobe Wire Fault, J50 Days, 00:00:03 ENTERPRISE Changing Root Port0 Days, 00:00:01 LINKUP J10 Days, 00:00:01 COLDSTART NONE0 Days, 00:00:07 ENTERPRISE Configuration script execution finished:0 Days, 00:00:01 LINKUP J10 Days, 00:00:07 COLDSTART NONE0 Days, 00:00:07 ENTERPRISE Configuration Reinitialized


3 - 21

Notes:


Trap Messages and Alarms (Contd)

Alarms Tigris is able to detect equipment failures or incoming signal failures. When a failure is detected, Tigris sends messages to the console and network equipment manager stations to alert operators to network equipment events.

Event notifications can be either ‘alarmed’ or ‘non-alarmed’. ‘Alarmed’ events are displayed on the console and to network equipment managers. Corresponding LEDs on the alarm panel are also lit. ‘Non-alarmed’ events are also displayed on the console, but the LEDs on the alarm panel are not activated.

‘Alarmed’ and ‘non-alarmed’ event notifications are displayed on the console at the time of occurrence. They can also be displayed at either the console or the network equipment manager station. Alarms designated as Critical, Major, and Minor events are ‘alarmed’. They have visual alarm indicators (LEDs) that remain lit until all alarms of the corresponding severity level are cleared. Only alarm entries for ‘alarmed’ events’ need to be cleared.

No operator intervention is required to manage the visual alarm indicators. When the condition causing the failure has been cleared, the corresponding alarm LED is automatically extinguished, provided that no other alarms of that severity level are pending.

Alarms Conditions for PRA

Before any changes are applied to the default configuration, display the alarm table and take note of any initial alarm conditions raised, using the command:

display alarm table

Refer to the Command Reference Guide for more information regarding Alarm Manager and the alarm table.

Default settings cover 90% of standard installations. Beyond that, any initial alarms should be resolved after the interface (s) has been reconfigured to the proper settings.

Settings particular to PRA or AXE-connected PRA are discussed in the next two sections.

Troubleshooting the Tigris PRA Interface

� Determine the nature of the alarm condition; verify DS1 settings against line provisioning

� Use loopback tests to help isolate the point of failure� Test against a known good connection


3 - 22


Figure 3.11

Tigris/AXE PRA Interconnection

Tigris

E1/T1MAU

ETP

TS ETB

LSM-PRA


AXE


3 - 23

Notes:


Trap Messages and Alarms (Contd)

Alarms on the DL2 interface in AXE

If the traffic connection over the DL2 interfaces between a TSM and Tigris is broken the AXE reports the alarm Switching Network Terminal Fault. Alarms one and two in the diagram.

The cause for the alarm can be:

� The cabling and wiring

� A faulty DL2 Interface card in Tigris

The Operational Instruction (OPI) to follow for solving the alarm is Integrated Access System, Central Access Server, Switching Network Terminal, Repair. Doc. No 3/154 31 - ANT 308 02

If the signalling connection via the STOC over the Ethernet is broken, the AXE gives the alarm Open Communication Error-alarms three, four and five in the diagram.

The cause for the alarm can be:

� A STOC fault. The alarm RP Fault is reported as well.

� The STOC can be manually or automatically blocked.

� The IP/Network addresses for the subnet is wrong.

The OPI, Open Communication Error, should be used to resolve the alarm.

Note: For both the DL2 and PRA connections all the operation and maintenance (O&M) is done by the AXE in the software block OMS.


3 - 24


Figure 3.12

DL2 Alarms on AXE

TSM - BTSM - A

STOC

DL2 IC

Modem IC

Modem IC

Modem IC

Modem IC

Modem IC

CC/Eth/WANEthernet

IntermediateAccess Network

1

2

34 5


3 - 25

Notes:


Self Test

1. What is Etheric?

2. If an outgoing Ethernet connection was needed, how would this be achieved?

3. What is a CIC?

4. What is the function of the TRH board?

5. What function has an access group?

6. When do Trap messages appear?

7. How does AXE deal with faults on Tigris?


3 - 26

Documents

03802 data com.pdf