SS7ATM_product Description COMPAQ 1.0

IN7 V4.1 - High Speed Signaling Links over ATM networksProduct 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 Page 1 of 24

__________________________________ 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. REFERENCE DOCUMENTS........................................................................................................................ 83.2. ASSOCIATED DOCUMENTS....................................................................................................................... 8

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

4.1. SS7ATM CONTEXT................................................................................................................................. 94.1.1. The ATM feature into IN7 stack......................................................................................................94.1.2. Metrics for calibrating IN7 SAAL...................................................................................................9

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

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

5.1. GOAL REQUIREMENTS........................................................................................................................... 115.1.1. Mixed configuration..................................................................................................................... 115.1.2. Graphical Interface...................................................................................................................... 115.1.3. Standard recommendations........................................................................................................... 11

5.2. NON-GOAL REQUIREMENTS................................................................................................................... 115.2.1. Postponed requirements............................................................................................................... 115.2.2. Waiting-list requirements............................................................................................................. 11

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

6.1. ATM CONNECTIVITY............................................................................................................................ 146.1.1. Firmware..................................................................................................................................... 146.1.2. Handling congestion and recovery in the board............................................................................146.1.3. Board configuration and management..........................................................................................146.1.4. IN7 Trunk and HSSL entities state relations..................................................................................14

6.2. SAAL IMPLEMENTATION....................................................................................................................... 146.3. SAAL LAYER MANAGEMENT INTERFACE (LMI)...................................................................................15

6.3.1. SAAL Entity Management............................................................................................................. 156.3.2. TRUNK Entity Management......................................................................................................... 166.3.3. HSSL Entity Management............................................................................................................. 17

6.4. CONFIGURING SAAL VIA S7MP SCRIPTS...............................................................................................186.5. IMPACTS ON EXISTING IN7 COMPONENTS...............................................................................................19

6.5.1. DNB device driver........................................................................................................................ 196.5.2. Management APIs........................................................................................................................ 20

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

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

7.1. ENVIRONMENT...................................................................................................................................... 227.1.1. Hardware..................................................................................................................................... 227.1.2. Software....................................................................................................................................... 227.1.3. Users............................................................................................................................................ 22

7.2. PERFORMANCE...................................................................................................................................... 227.3. INSTALLATION AND PACKAGING............................................................................................................23

7.3.1. Installation................................................................................................................................... 237.3.2. Packaging.................................................................................................................................... 23

7.4. LICENSING............................................................................................................................................ 237.5. PUBLICATIONS AND TRAINING............................................................................................................... 23


7.5.1. Publications................................................................................................................................. 237.5.2. Training....................................................................................................................................... 23

7.6. INTERNATIONALIZATION........................................................................................................................ 247.7. COMPATIBILITY.................................................................................................................................... 24

7.7.1. Product Compatibility.................................................................................................................. 247.7.2. Standard Conformance................................................................................................................. 24

7.8. USABILITY............................................................................................................................................ 247.9. RELIABILITY......................................................................................................................................... 247.10. MAINTAINABILITY............................................................................................................................. 247.11. SERVICE AND MAINTENANCE............................................................................................................247.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 concurrent engineering

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 Control This 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 ModeA 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 LayerLayer 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 videoAAL2: supports VBR traffic, such as packetized audio/videoAAL3/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 12.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 headerLMI Layer Management Interface

NNINetwork-Node Interface or Network-to-Network InterfaceThe 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 HierarchyA 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 AALDefined in Q.2100 series. Contains among others protocols like SAR, CPCS, SSCF-NNI and SSCOP.

SAR Segmentation And ReassemblySSCF-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 channelsUBR Unspecified Bit RateVBR Variable Bit Rate

VCIVirtual Channel Identifier – 16 bits in ATM cell headerA label used to identify connections between two ATM stations. Together, the VCI and VPI labels establish an ATM end-station address.

VPIVirtual Path Identifier – 8 bits in ATM cell headerUsed 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

SS7ATM - Product Requirements V 1.1 [R1] SS7ATM – Alternatives and Feasibility Study V 1.3 [R2]

3.2. Associated Documents

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:

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 requirementsN/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.

Identifiers Definition Syntax Settable Default valueNAME name of the entity OctetString[8] no 0UID uid of the entity OctetString[16] no emptyCharacteristicsVERSION software version OctetString[4] no X400SDU_SIZE size of SIF used at MTP3 layer uint32 no 272StatusSTATE disabled, available or failed uint32 no disabledCountersCREATION_TIME time of entity creation OctetString noNB_OF_ERRORS number or errors that have occurred Counter32 no 0


FEP_SUBSYSTEM

MTP2 MTP3SAAL

HSSLDATA-LINK TRUNK TRUNKHSSL

EventsSOFTWARE_ERROR event reported when counter increased uint32LEVEL_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.

Identifiers Definition Syntax Settable Default valueNAME name of the entity (1..9999999) OctetString[8] mandatory

at creationUID uid of the entity OctetString[16] no emptyCharacteristicsDEVICE_NAME physical device and associated port.

Example: pt39a0 (cf. chapter 6.5.1)String[6] mandatory

at creationFEP_NAME represents the FEP handling the link String mandatory

at creationTRUNK_TYPE type of trunk: E1, T1, J1, ADSL… uint32 noE1_REMOTE_ALARM specific to E1: USE_A, USE_AIS uint32 at creation USE_AE1_CRC4 specific to E1: ON, OFF uint32 at creation OFFT1_FRAMING specific to T1: D4, ESF uint32 at creation ESFT1_ENCODING specific to T1: B8ZS, AMI uint32 at creation B8ZST1_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_SBITuint32 at creation YA_NOT_TR

SMT1_OOF_RATIO specific to T1: 2OVER4, 2OVER5,

2OVER6uint32 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 xmit0..28-1


CELL_HEADER_VCI ATM cell header : VCI value on xmit0..216-1


CELL_HEADER_PTI ATM cell header : PTI value on xmit0..23-1


CELL_HEADER_CLP ATM cell header : CLP value on xmit0..1


ATM_SCRAMBLING defines ATM scrambling: ON, OFF uint32 at creation ONATM_IDLE_CELLS defines the idle cells: UNI, ITU

Empty header for UNI: 0x00000000Empty header for ITU: 0x01000000Empty 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 AAL5ATM_TIMESLOTS mask of all timeslots used to carry

ATM trafficuint32 at creation 0xFFFFFFFF

StatusSTATE disabled, available or alarm uint32 no disabledCountersCREATION_TIME time of entity creation OctetString noFW_TIMEOUT no response from firmware Counter32 noTKCNT_LOSES device unreachable Counter32 noRX_CARRIER_LOSES full frame of 0s received Counter32 noRX_SYNCHRO_LOSES synchronization loses Counter32 noAIS_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 noCODE_VIOLATIONS number of code violations Counter32 noCRC_ERRORS errors in CRC4 for E1, CRC6 for T1 Counter32 noEFS time of Error Free Seconds Counter32 noES time of Error Seconds Counter32 noSES time of Severely Error Seconds Counter32 noCSES time of Consecutively SES Counter32 noCRITICAL_ALARMS number of Critical Errors Counter32 noE1_FEBE specific to E1 if CRC4 is enabled Counter32 noSLIPS number of Elastic Store Slip

OccurrencesCounter32 no

HEC_ERRORS number of ATM HEC errors Counter32 noCELLS_TRANSMIT number of ATM cells transmitted Counter32 noCELLS_RECEIVED number of ATM cells received Counter32 noEventsTKCNT_LOSES event reported when device becomes

unreachableuint32

TKCNT_RECOVERED event report when device can be reached again

uint32

CRITICAL_ALARMS problem with the trunk line uint32CLEARED_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.

Identifiers Definition Syntax Settable Default valueNAME 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

UID uid of the entity OctetString[16] no emptyCharacteristicsTRUNK_NAME name of the already created TRUNK

entity linked to this HSSLOctetString[8] mandatory

at creationFEP_NAME represents the FEP handling the link,

derived from attached TRUNKString no

TB_SIZE transmit buffer size. uint32 at creation 128TB_CGT_ONSET congestion onset threshold in TB uint32 at creation 30TB_CGT_ABAT congestion abatement threshold in TB uint32 at creation 50RTB_SIZE retransmit buffer size uint32 no 128RB_SIZE receive buffer size. uint32 no 128K 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 4MAX_PD cf. Q2110 uint32 at creation 500MAX_STAT cf. Q2110 uint32 at creation 67TIMER_CC cf. Q2110 uint32 at creation 200 msTIMER_KEEPALIVE cf. Q2110 uint32 at creation 100 msTIMER_NORESP cf. Q2110 uint32 at creation 1500 msTIMER_POLL cf. Q2110 uint32 at creation 100 msTIMER_IDLE cf. Q2110 uint32 at creation 100 msTIMER_T1 cf. Q2140 uint32 at creation 5000 msTIMER_T2 cf. Q2140 uint32 at creation 30000 msTIMER_T3 cf. Q2140 uint32 at creation computed


N1 cf. Q2140 uint32 at creation 1000StatusSTATE 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 serviceSSCOP_STATE cf. Q2110 uint32 no idleCountersCREATION_TIME time of entity creation OctetString noPDU_TRANSMITTED number of SSCOP SD PDU

transmittedCounter32 no

PDU_RECEIVED number of SSCOP SD PDU received Counter32 noALIGNMENT_FAILED

number of alignment or proving failures

Counter32 no

UNSOLICITED_PDU number of receipt of unsolicited PDU Counter32 noUNSUCC_RETRANS number of unsuccessful retransmission Counter32 noLIST_ERRORS number of other list elements errors Counter32 noSD_LOSS SD PDU lost, must be retransmitted Counter32 noCREDIT_CONDITION number of credit condition Counter32 noDURATION_INS duration of link in the In Service state Counter32 noSL_FAILURE_ALL HSSL failure – all reasons Counter32 noSL_FAILURE_NORSP HSSL failure – No_RESPONSE timer Counter32 noSL_FAILURE_EXCES HSSL failure – Excessive error rate Counter32 noSL_FAILURE_CGT HSSL failure – Excessive congestion Counter32 noEventsIN_SERVICE link in service uint32FAILURE link failure (any reason) uint32CGT_START start of link congestion uint32CGT_END end of link congestion uint32ALIGNMENT_FAILED

initial alignment failure uint32

TIMEOUT timer (any) expired uint32START_PROVING start of proving period uint32STOP_PROVING end of proving period uint32PROVING_FAILURE proving was not successful uint32SSCOP_ERROR SSCOP error report (any reason

cf.Q2110)uint32

SSCOP_UNITDATA SSCOP Unit Data report (cf. Q2110) uint32LP_OUTAGE start of Local Processor Outage uint32LP_RECOVERED end of Local Processor Outage uint32SSCF_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 DescriptionTRUNK /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. LMI

HSSL /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/timert2 /timert2 Optional: cf. LMI/timert3 /timert3 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-NNISSCOP

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 Alpha Server – cPCI bus *

Proliant Intel –PCI bus Intel – cPCI rack *

*: 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 the overall 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):

IN7 Technical Descriptiongives a general description of the product capabilities and interfaces.

IN7 Installation Guidedescribes how to install IN7.

IN7 Entity Referencedescribes the IN7 entities with reference tables of their attributes.

IN7 Platform User’s Guidedescribes how to configure, control, and monitor a IN7 platform with reference to the supplied management program, System 7 Management Program (S7MP).

IN7 S7MP Command Referenceis the reference for the commands of the supplied management program, System 7 Management Program (S7MP).

IN7 Management Application Development Guideprovides information to help you use the IN7 Management API to develop SS7 network signaling point management applications.

IN7 Application Development Guideprovides 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 Guideprovides information to help you develop compliant service applications for use in American cellular networks.

IN7 Troubleshooting Guidegives 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.
