high speed ss7 prod descr compaq

7/23/2019 High Speed SS7 Prod Descr Compaq

http://slidepdf.com/reader/full/high-speed-ss7-prod-descr-compaq 1/25

Copyright © 2000 by Compaq Computer Corporation of 25

IN7 V4.1 - High Speed Signaling Links over ATM networks

Product Specifications

Abstract:

This document describes the functionality that would be implemented in the Version V4.1 of the IN7

product. This document is Compaq Confidential and may be distributed externally under non-disclosure

agreement.

Document Reference: SS7ATM_PSP_EXT

Date: July 7, 2000

Compaq Computer Corporation




__________________________________

Copyright © 2000 by Compaq Computer Corporation

All Rights Reserved.

Printed in France.

The information in this document may not be changed without express written agreement of Compaq

Computer Corporation.

Change History

Revision Date DescriptionV1.0 July 7, 2000 Creation




1. Table of contents

1. TABLE OF CONTENTS.......................................................................................................................................................3

2. INTRODUCTION...................................................................................................................................................................5

2.1. TERMS AND ACRONYMS................................................................................................................................................6

3. REFERENCE AND ASSOCIATED DOCUMENTS..........................................................................................................8

3.1. R EFERENCE DOCUMENTS.............................................................................................................................................8

3.2. ASSOCIATED DOCUMENTS...........................................................................................................................................8

4. EXECUTIVE SUMMARY......................................................................................................................................................9

4.1. SS7ATM CONTEXT .......................................................................................................................................................9

4.1.1. The ATM feature into IN7 stack .........................................................................................................................9

4.1.2. Metrics for calibrating IN7 SAAL .....................................................................................................................9

4.2. PRODUCT COMPONENTS..............................................................................................................................................9

5. DETAILED REQUIREMENTS .......................................................................................................................................... 11

5.1. GOAL REQUIREMENTS................................................................................................................................................11

5.1.1. Mixed configuration ......................................................................................................................................... 11

5.1.2. Graphical Interface...........................................................................................................................................11

5.1.3. Standard recommendations............................................................................................................................ 11

5.2. NON-GOAL REQUIREMENTS.......................................................................................................................................11

5.2.1. Postponed requirements .................................................................................................................................. 11

5.2.2. Waiting-list requirements ................................................................................................................................11

6. SOFTWARE CAPABILITIES .......................................................................................................................................... 13

6.1. ATM CONNECTIVITY.................................................................................................................................................14

6.1.1. Firmware............................................................................................................................................................. 14

6.1.2. Handling congestion and recovery in the board ........................................................................................14

6.1.3. Board configuration and management ......................................................................................................... 14

6.1.4. IN7 Trunk and HSSL entities state relations ...............................................................................................14

6.2. SAAL IMPLEMENTATION .........................................................................................................................................14

6.3. SAAL LAYER MANAGEMENT I NTERFACE (LMI)..................................................................................................15

6.3.1. SAAL Entity Management................................................................................................................................15

6.3.2. TRUNK Entity Management............................................................................................................................16

6.3.3. HSSL Entity Management................................................................................................................................17

6.4. CONFIGURING SAAL VIA S7MP SCRIPTS.................................................................................................................18

6.5. IMPACTS ON EXISTING IN7 COMPONENTS..............................................................................................................20

6.5.1. DNB device driver .............................................................................................................................................20

6.5.2. Management APIs .............................................................................................................................................20

6.6. SAAL POSSIBLE EVOLUTION.....................................................................................................................................21

7. GENERAL REQUIREMENTS ........................................................................................................................................... 22

7.1. E NVIRONMENT .............................................................................................................................................................22

7.1.1. Hardware ............................................................................................................................................................ 22

7.1.2. Software ..............................................................................................................................................................22

7.1.3. Users ....................................................................................................................................................................22

7.2. PERFORMANCE .............................................................................................................................................................22

7.3. I NSTALLATION AND PACKAGING.............................................................................................................................23

7.3.1. Installat ion .........................................................................................................................................................237.3.2. Packaging ..........................................................................................................................................................23

7.4. LICENSING.....................................................................................................................................................................23




7.5. PUBLICATIONS AND TRAINING .................................................................................................................................23

7.5.1. Publications.......................................................................................................................................................23

7.5.2. Training ..............................................................................................................................................................24

7.6. I NTERNATIONALIZATION ..........................................................................................................................................24

7.7. COMPATIBILITY..........................................................................................................................................................24

7.7.1. Product Compatibility .....................................................................................................................................24

7.7.2. Standard Conformance ....................................................................................................................................24

7.8. USABILITY ....................................................................................................................................................................24

7.9. R ELIABILITY ................................................................................................................................................................24

7.10. MAINTAINABILITY ................................................................................................................................................24

7.11. SERVICE AND MAINTENANCE ..............................................................................................................................25

7.12. EVOLVABILITY........................................................................................................................................................25




2. Introduction

The information in this document is subject to change without notice and should not be construed as a commitment

by Compaq Computer Corporation or its affiliated companies. Compaq Computer Corporation assumes no

responsibility for any errors that may appear in this document.

The purpose of the Product Specifications Phase is:

• To determine which key attributes from the Product Requirements will be implemented in the product. The

Product Requirements represent the complete set of customer needs. The Product Specifications is a detailed

subset of the Product Requirements, based on resources and other constraints.

• To translate the selected subset of the Product Requirements into Product Specifications used by engineers,

writers, and other team members during the project.

• To describe :

• Product deliverables

• Capabilities

• Features

• Functionality

• Quality

• Performance.

• To define minimum ship criteria, product volumes, and any other factors required by the product team.

The Product Specifications document definitively describes in measurable terms the goals, capabilities, and external

characteristics of a software product. It is a commitment by the development team of what it will build.

The Product Specifications document responds to the Product Requirements document. It will:

• Be the input for product design work • Help to identify the tasks involved in creating the product

• Be used to estimate the resources needed to deliver the product

• Be used as a measure against which the product is evaluated

This document should include, at least:

• High-Level Product Description

• Functional Description of High-Level Pieces

• Capabilities, Functions, Features and Option Support

• Prioritize these, ranking each one as the following:

• Goal

• Non-goal (postponed and waiting-list)

• Identify all interfaces that will require a specification to be written to assure interoperability and for concurrentengineering

• Map of Product Requirements to Product Specifications

• Show how the Product Specifications address each retained requirement

• Identify all the requirements that are not covered by the Product Specifications

• Restriction and Assumption from Product Requirements

Revision ControlThis document defines the contents of the product. Application of Documentation Control Procedure (TE-PRO-0016)

is vital for the project; after it has been finalized and approved, the Product Specifications are frozen. All change

must apply the Project Change Control procedure (TE-PRO-0012).

• The project team cannot add functionality that was not listed in the Product Specifications.• The project team cannot delete or reduce functionality that has been listed as a goal.




• The project team cannot change the category of functionality after the Product Specifications have been frozen

(for example, a goal requirement cannot be reclassified as a non-goal requirement and vice versa).

The Product Specifications document is the result of the study of the User Requirements detailed in the Product

Requirements document [R1]. Once finalized, the Product Specifications are the main input to update the first version

of Engineering Project Plan document that gathers the deliverables, milestones and costs.

2.1. Terms and acronyms

Term Description

ATM

Asynchronous Transfer Mode

A switching and multiplexing technology based on the segmentation of voice, video, and data traffic

into equal length cells which are then interleaved over a physical connection in a time-asynchronous

manner. This contrasts with TDM where different traffic sources are assigned fixed timeslots

AAL

ATM Adaptation Layer

Layer within the ATM model that supports Convergence Sublayer (CS) and Segmentation And

Reassembly (SAR) services into/out of ATM cells. Different AALs exist:AAL0: this layer nullifies AAL. Data to be sent should fit in an ATM 48 bytes cell.

AAL1: supports CBR traffic, such as video

AAL2: supports VBR traffic, such as packetized audio/video

AAL3/4: supports VBR traffic, such as Frame Relay, X25, SMDS. Being replaced by AAL5.

AAL5: leaner version of AAL3/4, supports Frame Relay, X25, IP,…

CBR Constant Bit Rate

CLPCell Loss Priority – 1 bit in ATM cell header : if set to 1, indicates that the cell can be discarded in

cased of congestion

CPCS Common Part Convergence Sublayer

E1European Signal Level 1

2.048 Mbps transport rate within the European PDH hierarchy, supporting 32x64 Kbps channels.

GFCGeneric Flow Control – 4 bits in ATM cell header, mostly used to extend number of VPIs supported,as

its use is not standardized yet.

HEC Header Control Error – checksum over the cell header

LMI Layer Management Interface

NNI

Network-Node Interface or Network-to-Network Interface

The NNI is better characterized as a switch-to-switch interface. The ATM Forum has defined a Private-

NNI (P-NNI) to connect switches within a single management domain.

PDH

Plesiosynchronous Transmission Hierarchy

A public transmission hierarchy based on a non-synchronous alignment of octets at different levels of

multiplexing. PDH is only bit-synchronous . PDH networks are in the process of being replaced with

SDH networks. Examples of PDH transmission rates include E1 and T1.

PTI Payload Type Identifier – 3 bits in ATM cell header

SAALSignaling AAL

Defined in Q.2100 series. Contains among others protocols like SAR, CPCS, SSCF-NNI and SSCOP.

SAR Segmentation And Reassembly

SSCF-NNI Service Specific Coordination Function at NNI (Q.2140)

SSCOP Service Specific Connection Oriented Protocol (Q.2110)

T1 1.544 Mbps transport rate, supporting 24 channels

UBR Unspecified Bit Rate

VBR Variable Bit Rate

VCI

Virtual Channel Identifier – 16 bits in ATM cell header

A label used to identify connections between two ATM stations. Together, the VCI and VPI labels

establish an ATM end-station address.

VPI

Virtual Path Identifier – 8 bits in ATM cell header

Used to identify each VP across the UNI or NNI. The VPI is an 8-bit field at the UNI; 12 bits at the NNI(no GFC).




Table 1 List of Terms and Acronyms




3. Reference and Associated Documents

All documents are available on IN7 Engineering Site Scape forum (SSF) ) located on http://teleng.vbe.cpqcorp.net/

under SS7 Engineering/Development Projects.

All the project documents are under SS7ATM SSF.

Note: the Product Specifications of the DNB device driver should be available soon under IN7 Engineering SSF, but

as it is not ready at the time of writing the present document, it is not referenced here below.

3.1. Reference Documents

q SS7ATM - Product Requirements V 1.1 [R1]

q SS7ATM – Alternatives and Feasibility Study V 1.3 [R2]

3.2. Associated Documents

q ITU-T Recommendations Series Q.2100 [A1]




4. Executive Summary

4.1. SS7ATM context

4.1.1. The ATM feature into IN7 stack

This chapter briefly describes the new IN7 V4.1 feature, which is a high-speed signaling links over ATM function.

The main objective is to provide the ability to carry MTP3 traffic over high load link sets between any STP and IN7

supporting this capability.

This objective will be achieved by using the ITU-T SAAL specifications and AAL5 protocol over E1/T1 channels.

The IN7 stack implementation for high-speed signaling links will look like:

MTP3 / MTP3-BQ.704 / Q.2110

SSCF at NNIQ.2140

SSCOPQ.2110

ATM layer (AAL5)

Physical layer (PDH 2 Mbit/s link)

G.804

SAALQ.2100

I.363

The physical layer will be performed by using the PT-PCI37x-p board from PTI which include the MPC860SAR

processor and provides dual E1/T1 connectivity.

This processor handles AAL5 layer on top of ATM connectivity.

The SAAL layer is a new component to be implemented and that will be fully integrated into the IN7 stack. It will be

implemented as running within the FEP process, but may be eventually embedded in the board later on, in case of

performance problems.

4.1.2. Metrics for calibrating IN7 SAAL

SAAL layer developed into IN7 product should conform to relative ITU-T Q.2100 recommendations.

IN7 SAAL layer should be compatible at least with relevant Ericsson Switch.

4.2. Product Components

Here is a list of new components involved by this project:

• SAAL software




• SAAL LMI

• Firmware handling AAL5

• SAAL, TRUNK (under SAAL) and HSSL management entities

Here is a list of existing components to be modified:

• Management relative packages (S7MP scripts, MGT API, DIR, FEP)

• Management tools (ss7configure, GUI, DNB tools)

• MTP2_SWITCH

• MTP3

• DNB Device driver and Starlet




5. Detailed Requirements

5.1. Goal requirements

The following requirements are complementary points to ITU-T (and ANSI) recommendations in order to fully inter-

work with other vendors’ high-speed signaling links implementations, according that Telcordia (formerly Bellcore) do

not provide any recommendations for such specifications.

• VPI and VCI values will be fully configurable via standard IN7 management procedures on new HSSL entities.

• Errors reporting and monitoring will conform to IN7 standard error reporting mechanism.

• G.804 compliance is fully performed by the MPC860SAR processor tuning, including:

• scrambling

• no use of TS0 and TS16 for E1 links (implicit use of G.804)

• Maximum supported signaling information size is 272 octets

• Possibility to have mixed link sets, i.e. regular 64/56 Kbit/s over E1/T1 or V35 links and ATM over E1/T1 links

within a same link set.

IN7 MTP3 will support extended changeover messages (XCO/XCA) and will support an FSN encoded on 3

octets when changeover occurs on a high-speed link. However, the maximum number of messages to be

retransmitted is limited to 128 per link (regular MTP2 requirement).

5.1.1. Mixed configurationA mixed configuration of regular E1/T1 links (or V35 links) and ATM links will be supported among the same

platform. However, this capability is not applicable on a single FEP.

5.1.2. Graphical InterfaceAs this new feature will be fully backward compatible, the management of ATM functionality through GUI interface

will also be supported. In fact, the impact on GUI is not so important, as an SS7 link within GUI will map either a

High-Speed Link or a Regular Link.

5.1.3. Standard recommendationsCHINA and ANSI recommendations (T1.645 for SSCF-NNI, T1.637 for SSCOP) should be implemented.

5.2. Non-Goal requirements

The following points are non-goals or limitations addressed by the current high-speed links feature implementation:

• 4 Koctets signaling information size (Q.2210 recommendation but not a requirement)

This feature will not be implemented in IN7 MTP3 as no upper layer use this capability

• OC-3, OC-12, J1 connections

5.2.1. Postponed requirements N/A

5.2.2. Waiting-list requirements• full support of Q.2210 recommendations (4 Koctets signaling information size) if needed by upper layers to

MTP3-B




• J1 and OC-3 connections

• mixed configuration within a same FEP

• embedded SAAL software

• SS7-MTP2 firmware embedded in PT-PCI37x-p ATM boards, i.e. those boards will support only ATM specific

firmware




6. Software Capabilities

The software implementation for handling high-speed signaling links can be depicted as:

HOST

PCI / cPCI Bus

BOARD

device driver

UpStream / DownStream

Boot Background

AAL5 API

MPC860SAR

Framer E1/T1

SAAL

LMI

SSCF-NNI

SSCOP

MTP2_SWITCH

MTP3 (+ XCO/XCA)

STARLET




6.1. ATM Connectivity

The hardware board handling ATM connectivity with dual E1/T1 links is the PTI PC-37x that includes the

MPC860SAR processor. This processor handles CPCS and SAR in order to provide AAL5 transport layer.

6.1.1. FirmwareIn order to send SSCOP messages coming from the host through an ATM link using AAL5 (and vice-versa), a

firmware should be developed based on current firmware architecture for PTI boards. This firmware is made up from

different parts:

• programming the E1/T1 framer

• an AAL5 API to provide an easy way to transmit/receive frames over ATM network through the processor

serial interface, including:

• general MPC860SAR initialization

• creation/deletion of an AAL5 channel

• transmission/reception of frames over an opened AAL5 channel

•

issue commands• report events and counters

• a bootstrap

• downstream and upstream modules for storing messages from/to host

• a background scheduler for processing messages from host and from network

6.1.2. Handling congestion and recovery in the boardOn transmission, DNB device driver handles congestion for downstream messages. When congestion occurs, driver

reports an error exception on write() driver call.

On reception, firmware relies on the mechanism implemented within MPC860SAR processor. When reception buffer

is full, any incoming AAL5 message is discarded. ATM cells can also be discarded in case of congestion if CLP bit

in cell header is set to 1.

On board failure, there is an automatic restart of firmware, as it is done currently with regular E1/T1 boards. There is

also an automatic reconfiguration mechanism used by the board at restart.

Upon a board reset or failure, DNB driver will detect this event and will report an alarm to IN7 management layer.

6.1.3. Board configuration and managementThe ATM board will be configured and managed in the same way as it is done currently with regular E1/T1 boards.

The same tools will be used to download the firmware (pt_download) and to trace its activity (pt_trace). The

firmware version will be reported via the tracing mechanism.

6.1.4. IN7 Trunk and HSSL entities state relationsThe state relations between HSSL and Trunk entities are based on the same model than the one used at MTP2 level

for Trunk and Data-Link entities. In ATM case, there is only one HSSL per Trunk, so that a critical problem occurring

on a trunk entails an HSSL going out of service.

6.2. SAAL implementation

The SAAL software will be implemented within the IN7 stack. It will be the transport layer used by MTP3 when

carrying information over high-speed signaling links. IN7 SAAL will implement SSCF-NNI (Q.2140) and SSCOP

(Q.2110) recommendations.




As an IN7 entity, SAAL software will be fully configurable via IN7 management interface. S7MP scripts will be used

to configure these high-speed signaling links. IN7 GUI tool will handle new SAAL entities transparently with the

same user interface.

SAAL software, its protocol entities and its LMI objects, will be implemented as C++ classes. First implementation of

these classes will fully integrate the FEP process. However, SAAL software will react as an independent thread.

Indeed, it could be eventually embedded in the board so that an independent thread will be quite straightforward to

embed.

SSCOP protocol is the main class for handling SAAL traffic over ATM AAL5 connections. In order to provide a

reliable transfer for MTP3 packets, it implements a transmitter and a receiver as specified in Q2110.

SSCF-NNI specifies the interface for using SSCOP. An API at SSCF-NNI level will be developed for MTP3 level use.

This API allows to pass commands from MTP3 to SAAL and to report indications from SAAL to MTP3.

MTP3 (or MTP2_SWITCH, to be defined in design) should be modified in order to use SAAL instead of MTP2 as a

data-link transport layer. Also, MTP3 should handle FSN/BSN encoded on 3 octets for extended changeover

procedures.

6.3. SAAL Layer Management Interface (LMI)

The FEP subsystem entity tree with the new SAAL branch will look like:

SAAL entity is a meta-entity (like MTP2). It cannot be instantiated more than once.

HSSL entity and TRUNK entity (different from the one defined under MTP2) can be instantiated as many high-speed

links to be handled. Even non-local high-speed links can be instantiated in SAAL LMI (for LMI redundancy

purpose).

There should be always only one HSSL entity for one TRUNK entity. The TRUNK entity is to be defined before the

definition of an HSSL entity, as there is a reference to an TRUNK into HSSL characteristics.

Note: all timer characteristics will be reported in hundredth of seconds, for IN7 coherence.

6.3.1. SAAL Entity Management

SAAL entity is a container entity. It can not be instantiated more than once.

I denti f iers Def ini tion Syntax Settable Default value

NAME name of the entity OctetString[8] no 0

UID uid of the entity OctetString[16] no empty

Characteristics

VERSION software version OctetString[4] no X400

SDU_SIZE size of SIF used at MTP3 layer uint32 no 272

Status STATE disabled, available or failed uint32 no disabled

FEP_SUBSYSTEM

MTP2 MTP3SAAL

HSSLDATA-LINK TRUNK TRUNK HSSL




Counters

CREATION_TIME time of entity creation OctetString no

NB_OF_ERRORS number or errors that have occurred Counter32 no 0

Events

SOFTWARE_ERROR event reported when counter increased uint32

LEVEL_FAILURE event reported when program stopped uint32

6.3.2. TRUNK Entity Management

SAAL TRUNK entity is equivalent to MTP2 TRUNK entity when running signaling protocols over High-Speed

Links. This entity contains all characteristics to fully define the physical interface, whether it is E1, T1, etc… It also

contains all characteristics to define the ATM protocol running on that link. If, in the future of IN7, SAAL will run on

top of optical fibers, then TRUNK entity will contain extra characteristics to fully define OC links.


NAME name of the entity (1..9999999) OctetString[8] mandatory

at creation


Characteristics

DEVICE_NAME physical device and associated port.

Example: pt39a0 (cf. chapter 6.5.1)

String[6] mandatory

at creation

FEP_NAME represents the FEP handling the link String mandatory

at creation

TRUNK_TYPE type of trunk: E1, T1, J1, ADSL… uint32 no

E1_REMOTE_ALARM specific to E1: USE_A, USE_AIS uint32 at creation USE_A

E1_CRC4 specific to E1: ON, OFF uint32 at creation OFF

T1_FRAMING specific to T1: D4, ESF uint32 at creation ESF

T1_ENCODING specific to T1: B8ZS, AMI uint32 at creation B8ZS

T1_BANDWIDTH specific to T1: 56Kbit/s, 64Kbits/s uint32 at creation 56T1_YELLOW_ALARM specific to T1: YA_NOT_TRSM,

YA_IN_BIT2, YA_IN_SBIT

uint32 at creation YA_NOT_TRS

M

T1_OOF_RATIO specific to T1: 2OVER4, 2OVER5,

2OVER6

uint32 at creation 2OVER6

CELL_HEADER_GFC ATM cell header : GFC value on xmit

0..24-1

uint32 at creation 0

CELL_HEADER_VPI ATM cell header : VPI value on xmit

0..28-1


CELL_HEADER_VCI ATM cell header : VCI value on xmit

0..216

-1


CELL_HEADER_PTI ATM cell header : PTI value on xmit

0..23-1


CELL_HEADER_CLP ATM cell header : CLP value on xmit

0..1


ATM_SCRAMBLING defines ATM scrambling: ON, OFF uint32 at creation ON

ATM_IDLE_CELLS defines the idle cells: UNI, ITU

Empty header for UNI: 0x00000000

Empty header for ITU: 0x01000000

Empty payload : 0x6A6A6A6A

uint32 at creation ITU

ATM_QOS_CLASS Quality of Service: CBR, UBR or VBR uint32 at creation VBR

ATM_A_LAYER AAL0, AAL1, AAL5 uint32 no AAL5

ATM_TIMESLOTS mask of all timeslots used to carry ATM

traffic

uint32 at creation 0xFFFFFFFF

Status

STATE disabled, available or alarm uint32 no disabled

Counters





FW_TIMEOUT no response from firmware Counter32 no

TKCNT_LOSES device unreachable Counter32 no

RX_CARRIER_LOSES full frame of 0s received Counter32 no

RX_SYNCHRO_LOSES synchronization loses Counter32 no

AIS_TRANSMITTED number of transmitted AIS Counter32 no

AIS_RECEIVED For T1: number of blue alarms Counter32 noALARM_REMOTE For E1: A bit set. For T1: yellow alarm Counter32 no

CODE_VIOLATIONS number of code violations Counter32 no

CRC_ERRORS errors in CRC4 for E1, CRC6 for T1 Counter32 no

EFS time of Error Free Seconds Counter32 no

ES time of Error Seconds Counter32 no

SES time of Severely Error Seconds Counter32 no

CSES time of Consecutively SES Counter32 no

CRITICAL_ALARMS number of Critical Errors Counter32 no

E1_FEBE specific to E1 if CRC4 is enabled Counter32 no

SLIPS number of Elastic Store Slip

Occurrences

Counter32 no

HEC_ERRORS number of ATM HEC errors Counter32 noCELLS_TRANSMIT number of ATM cells transmitted Counter32 no

CELLS_RECEIVED number of ATM cells received Counter32 no

Events

TKCNT_LOSES event reported when device becomes

unreachable

uint32

TKCNT_RECOVERED event report when device can be

reached again

uint32

CRITICAL_ALARMS problem with the trunk line uint32

CLEARED_ALARMS alarm condition has cleared uint32

6.3.3. HSSL Entity Management

SAAL HSSL entity is equivalent to MTP2 DATA_LINK entity when running signaling protocols over High-Speed

Links. . This entity contains all characteristics to fully define the SAAL protocol running onto that link.


NAME name of the entity representing the PLN

used to define an MTP3 link (1..4096).

Note that this name should be unique

among (HSSL + DATA-LINK) set.

OctetString[8] mandatory

at creation


Characteristics TRUNK_NAME name of the already created TRUNK

entity linked to this HSSL

OctetString[8] mandatory

at creation

FEP_NAME represents the FEP handling the link,

derived from attached TRUNK

String no

TB_SIZE transmit buffer size. uint32 at creation 128

TB_CGT_ONSET congestion onset threshold in TB uint32 at creation 30

TB_CGT_ABAT congestion abatement threshold in TB uint32 at creation 50

RTB_SIZE retransmit buffer size uint32 no 128

RB_SIZE receive buffer size. uint32 no 128

K cf. Q2110, this value is derived from

SAAL::SDU_SIZE (0..65528)

uint32 no computed

J cf. Q2110 (0..65524) uint32 at creation 4MAX_CC cf. Q2110 uint32 at creation 4

MAX_PD cf. Q2110 uint32 at creation 500




MAX_STAT cf. Q2110 uint32 at creation 67

TIMER_CC cf. Q2110 uint32 at creation 200 ms

TIMER_KEEPALIVE cf. Q2110 uint32 at creation 100 ms

TIMER_NORESP cf. Q2110 uint32 at creation 1500 ms

TIMER_POLL cf. Q2110 uint32 at creation 100 ms

TIMER_IDLE cf. Q2110 uint32 at creation 100 ms

TIMER_T1 cf. Q2140 uint32 at creation 5000 msTIMER_T2 cf. Q2140 uint32 at creation 30000 ms

TIMER_T3 cf. Q2140 uint32 at creation computed

N1 cf. Q2140 uint32 at creation 1000

Status

STATE disabled, out of service, alignment,

proving, aligned ready, in service,

unknown (in case of a non-local link)

uint32 no disabled

SSCF_STATE cf. Q2140 uint32 no out of service

SSCOP_STATE cf. Q2110 uint32 no idle

Counters


PDU_TRANSMITTED number of SSCOP SD PDU transmitted Counter32 no

PDU_RECEIVED number of SSCOP SD PDU received Counter32 no

ALIGNMENT_FAILED number of alignment or proving failures Counter32 no

UNSOLICITED_PDU number of receipt of unsolicited PDU Counter32 no

UNSUCC_RETRANS number of unsuccessful retransmission Counter32 no

LIST_ERRORS number of other list elements errors Counter32 no

SD_LOSS SD PDU lost, must be retransmitted Counter32 no

CREDIT_CONDITION number of credit condition Counter32 no

DURATION_INS duration of link in the In Service state Counter32 no

SL_FAILURE_ALL HSSL failure – all reasons Counter32 no

SL_FAILURE_NORSP HSSL failure – No_RESPONSE timer Counter32 no

SL_FAILURE_EXCES HSSL failure – Excessive error rate Counter32 noSL_FAILURE_CGT HSSL failure – Excessive congestion Counter32 no

Events

IN_SERVICE link in service uint32

FAILURE link failure (any reason) uint32

CGT_START start of link congestion uint32

CGT_END end of link congestion uint32

ALIGNMENT_FAILED initial alignment failure uint32

TIMEOUT timer (any) expired uint32

START_PROVING start of proving period uint32

STOP_PROVING end of proving period uint32

PROVING_FAILURE proving was not successful uint32

SSCOP_ERROR SSCOP error report (any reasoncf.Q2110)

uint32

SSCOP_UNITDATA SSCOP Unit Data report (cf. Q2110) uint32

LP_OUTAGE start of Local Processor Outage uint32

LP_RECOVERED end of Local Processor Outage uint32

SSCF_REPORT events (any) detected by SSCF (cf.

Q2140)

uint32

6.4. Configuring SAAL via S7MP scripts

New qualifiers need to be defined for SAAL, TRUNK and HSSL entities. These new tags definitions will be:

Entity Qualifiers Shortcut Description




TRUNK /devname /d Mandatory: physical device and associated port

/fepname /f Mandatory: FEP where link is physically attached

/e1remotealarm /e1r Optional: cf. LMI

/e1crc4 /e1c Optional: cf. LMI

/t1framing /t1f Optional: cf. LMI

/t1encoding /t1e Optional: cf. LMI

/t1bandwidth /t1b Optional: cf. LMI/t1yellowalarm /t1y Optional: cf. LMI

/t1oofratio /t1o Optional: cf. LMI

/gfc /g Optional: cf. LMI

/vpi /vp Optional: cf. LMI

/vci /vc Optional: cf. LMI

/pti /p Optional: cf. LMI

/clp /c Optional: cf. LMI

/scrambling /s Optional: cf. LMI

/idlecells /i Optional: cf. LMI

/tkcntloses /tkcntl event: cf. LMI

/tkcntrecovered /tkcntr event: cf. LMI

/criticalalarms /cr event: cf. LMI

/clearedalarms /cl event: cf. LMIHSSL /trunkname /tr Mandatory: name of physical TRUNK

/tbsize /tbs Optional: cf. LMI

/tbcgtonset /tbcgto Optional: cf. LMI

/tbcgtabat /tbcgta Optional: cf. LMI

/k /k Optional: cf. LMI

/j /j Optional: cf. LMI

/maxcc /maxc Optional: cf. LMI

/maxpd /maxp Optional: cf. LMI

/maxstat /maxs Optional: cf. LMI

/timercc /timerc Optional: cf. LMI

/timerkeepalive /timerk Optional: cf. LMI

/timernoresp /timern Optional: cf. LMI/timerpoll /timerp Optional: cf. LMI

/timeridle /timeri Optional: cf. LMI

/timert1 /timert1 Optional: cf. LMI



/n1 /n Optional: cf. LMI

/inservice /i event: cf. LMI

/failure /f event: cf. LMI

/cgtstart /cgts event: cf. LMI

/cgtend /cgte event: cf. LMI

/alignmentfailed /a event: cf. LMI

/timeout /timeo event: cf. LMI

/startproving /sta event: cf. LMI

/stopproving /sto event: cf. LMI

/provingfailure /pro event: cf. LMI

/sscoperror /sscope event: cf. LMI

/sscopunitdata /sscopu event: cf. LMI

In the case of the first implementation of SAAL layer, no new verb will be defined within SAAL.




6.5. Impacts on existing IN7 components

6.5.1. DNB device driverThe device driver should be able to identify new ATM boards. Although PT-PCI37x-p is quite identical to classical

PT-PCI37x board in terms of hardware, a different prefix name will be used for both types of board at management

level (s7mp) in order to differentiate their capabilities. Indeed, at configuration level (ss7configure), board types

should be different in order to download the right firmware to the relevant board. Device driver (and Starlet) should

be modified to handle the new device-id and associated firmware.

DNB tools should also be modified to download ATM specific firmware to relevant boards.

Each framer (attached to a trunk) of the board could be used to handle traffic, so that two trunks can be handled by a

single board. The following naming convention will be used to refer to a PTI ATM board:

pt39xn, where x is the slot where the board is assigned to the rack, and where n is the trunk used (0 or 1).

Note that no divert timeslots facility will be available.

The driver will provide two communication channels for dialog between firmware and hosted SAAL, that is one for

data and the other one for management purpose. In case of board congestion, a kind of priority will be given to

management channel versus data channel.

6.5.2. Management APIsOnly portable API (on all OS) will support the new functionality.

However, non-portable API (VMS case only) will still be compatible with this version of IN7, even if the new

functionality will not be supported for that API.




6.6. SAAL possible evolution

In the case of non-satisfactory performance of FEP process including SAAL software, and supposing that board is

capable to support the SAAL workload, the SAAL part will be eventually embedded in board, as depicted below:

HOST

PCI / cPCI bus

BOARD

Note: current experience of PTI boards show that there could be some memory problems when handling new

firmware.

device driver

UpStream / DownStream

Boot Background

AAL5 API

MPC860SAR

Framer E1/T1

SAALLMI

SSCF-NNI

SSCOP

MTP2_SWITCH

MTP3 / MTP3-B

STARLET

SAAL LMI




7. General Requirements

7.1. Environment

7.1.1. Hardware

ATM connectivity should be fully compatible to both PCI and CompactPCI bus interfaces.

This feature is targeted on Compaq Alpha Servers (PCI and cPCI) and on Proliant Intel (PCI bus on cPCI frame).

Connectivity will support E1 and T1 links.

Hot-swap capability will not be supported in first firmware versions.

7.1.2. Software

High-speed signaling links feature will be fully integrated to IN7 V4.1 (ITU, ANSI and CHINA) and will be available

on following operating systems:

Hardware Platform Tru64

UNIX

4.0F and +

DIGITAL

OpenVMS

V7.2 and +

Windows

NT 4.0

Windows

2000

Alpha Server – PCI bus a a

Alpha Server – cPCI bus a*

Proliant Intel –PCI bus a

Intel – cPCI rack a*

*: Only if cPCI rack available before end of September 2000.

All others platforms are not supported.

7.1.3. Users

N/A

7.2. Performance

New SAAL feature should not consume too much CPU and memory, so that the workload of the hosted SAAL

software is expected to be equivalent of the workload of the hosted MTP2 software for running V35 links, at a same

throughput level. IN7 performances should also be equivalent to standard E1/T1 links in terms of throughput, either

considering board performances (around 850 TPS) than host performances (today more than 2000 TPS per FEP,

depending on FEP capacity).

RTT (round-trip time) delay should be equivalent to the one observed for regular IN7 E1/T1 connections for a same

throughput. That is, it should not be more than 80 ms when running a standard TCAP application at 50% of theoverall maximum capacity.




An optional feature for embedding SAAL software in the board should be available, if needed, in future releases of

IN7 high-speed signaling links in order to have an equivalent FEP activity when running classical E1/T1 links, if and

only ATM board supports it in terms of performance as well.

7.3. Installation and Packaging

7.3.1. Installation

This feature will conform to IN7 installation strategy.

7.3.2. Packaging

This feature will conform to IN7 packaging strategy.

7.4. Licensing

This feature will be part of general IN7 licensing.

7.5. Publications and Training

7.5.1. Publications

All the documentation and publication will be detailed in the SS7ATM documentation plan.

The documentation set supplied with IN7 will be modified in order to reflect about this new high-speed signaling link

feature implementation. The full documentation set contains (documents to be modified in bold):

• I N7 Techni cal Descri ption

gives a general description of the product capabilities and interfaces.

• I N7 In stallation Guide

describes how to install IN7.

• I N7 Enti ty Reference

describes the IN7 entities with reference tables of their attributes.

• I N7 Platform User’ s Guide

describes how to configure, control, and monitor a IN7 platform with reference to the supplied management

program, System 7 Management Program (S7MP).

• I N7 S7MP Command Reference

is the reference for the commands of the supplied management program, System 7 Management Program

(S7MP).

• I N7 Management Application Development Gui de

provides information to help you use the IN7 Management API to develop SS7 network signaling point

management applications.

• IN7 Application Development Guide

provides information to help you develop service applications for SS7 networks using the IN7 Application

Programming Interfaces.

• IN7 Application Part, Volume 1, IS41-C API User’s Guide

provides information to help you develop compliant service applications for use in American cellular networks.

• I N7 Troubleshooting Guide

gives diagnosis and recovery guidelines to help you solve problems with IN7 and its associated software .




7.5.2. Training

IN7 training courses need to be updated.

7.6. Internationalization

N/A

7.7. Compatibility

7.7.1. Product Compatibility

This new functionality will be fully compatible to IN7 V4.1 and higher versions. There will be an ascendant

compatibility on existing IN7 software, so that IN7 including SAAL feature should behave exactly the same as it

does today while not using any functionality of this new feature, for example using only DNBC4 or DNBE1 boards.It should be backward compatible also for MGT API purpose.

7.7.2. Standard Conformance

Firmware:

Firmware will be identical whatever the SS7 protocol suite used, that is ITU-T, CHINA or ANSI.

But, firmware will be slightly different if it is running on a PCI bus or on a cPCI bus.

Rolling upgrade is not supported.

SAAL:

This section lists the International Standards applicable to the IN7 SAAL component:

1. Q.2110 B-ISDN AAL – SSCOP2. Q.2140 B-ISDN AAL – SSCF-NNI

However, first implementation of IN7 SAAL will not support the following features, which are optional in the above

standards:

• support sending of UD PDU

• support sending of MD PDU

• local user initiated resynchronization procedures

• remote user initiated resynchronization procedures

Also, IN7 SAAL first implementation will not support Q.2144 recommendation: B-ISDN AAL – LM for SAAL at NNI

7.8. Usability

The strategy for user interfaces in terms of help, training, error reporting will follow IN7 strategy. The IN7 trace

logging facility of the FEP will be used for SAAL software. The IN7 firmware logging facility will also be used within

the firmware.

7.9. Reliability

Firmware errors will be treated the same way as current errors occurring on standard E1/T1 boards.

7.10. Maintainability



This feature will conform to IN7 software product maintainability strategy.

7.11. Service and Maintenance

As SAAL software is fully integrated to IN7 product, maintenance service is available through IN7 common

maintenance procedures.

7.12. Evolvability

This new feature will conform to IN7 product strategy.