Overview of the ATM High-Speed Signaling Link LIM Operation

To other cards in the EAGLE , the ANSI ATM and E1 ATM high-speed signaling link cards look and operate similar to any other LIMs (with the exception of subtle differences related to load balancing for SCCP traffic), but has the potential for increased data throughput with respect to traditional EAGLE LIMs.

The ANSI and E1 ATM high-speed signaling link cards can perform gateway screening, copy and redirect, conversion and any of the other EAGLE features that any other LIM can perform (with the exception of link fault sectionalization).

A functional block diagram of the ATM high-speed signaling link is shown in Figure C-5.

Figure C-5 Functional Block Diagram of ATM High-Speed Signaling Link

The following sections provide more details for each of the new applications/processes (indicated by the bold boxes in Figure C-5) required for the ATM high-speed signaling link implementation. These sections will include information such as:

• the specification(s) that defines the layer
• highlights of the functionality provided by the application/process (what problems are being solved here)
• any limitations/restrictions from specifications that apply to the EAGLE implementation
• other information as appropriate

Applique

ANSI ATM

The ANSI ATM hardware consists of an AATM applique connected to an HCAP or HCAP-T main assembly. The AATM hardware provides the following functionality:

• support for the DS1, ATM, and AAL5CP layers of the ATM high-speed signaling link protocol stack as indicated in Figure C-1.
• DS1 Layer support

  • generate DS1 signals

  • support for DS1 defect reporting:

    • LOS
    • LOF
    • LCD
    • In-band AIS signals
  • support for loopback testing at the DS1 level
  • support for DS1 performance measurements and performance monitoring

• ATM Layer support

  • idle cell insertion/removal
  • provide adequate indications of ATM layer errors:
    • invalid ATM header patterns
    • unsupported VPI/VCI combinations
    • unsupported PTI values
    • cells discarded due to header error control
    • out of cell delineation anomalies
  • header error control field to be automatically inserted/checked by the hardware
  • CLP field of cells received is made available to software
  • ability to DMA received cells directly to DIMM receive buffers
  • ability to DMA cells to transmit directly from DIMM transmit buffers
  • needs to support interleaved transmit/reception of data from different VPI/VCI combinations, or from OAM F5 flows as opposed to user data flows, these need to each be passed to higher layers using different queues or data structures
  • congestion indications for cells are made available to software; software can set the congestion indications for outbound traffic.
• OAM F5 cell support
  • only end to End OAM F5 cells for a VCC need to be supported
  • shall support generation (outbound) and processing (inbound) of OAM cell types for VCC F5 flows
  • shall indicate reception of these cells in a distinct manner from user data cells
  • provide CRC-10 checking/generation for these frames

• AAL5CP Layer support

  • perform the segmentation/reassembly required for user data cells and ability to pass user data to/from the SSCOP in an efficient manner (whether this is via some linked list of ATM cells that together make up 1 AAL5CP_PDU, or via regrouping ATM cells as they arrive into 1 continuous AAL5CP_PDU is implementation dependent).
  • provide CRC-32 generation/checking for AAL5CP_PDUs
  • should stuff outbound AAL5CP_PDUs with 0 in the CPI field
  • appropriate error checking and indications for errors
    • CRC errors
    • Length errors
    • CPI errors
  • some fields of the AAL5CP_PDU need to be passed to/from the higher layers
    • UU
    • CLP
    • Congestion indication

E1 ATM

The E1 ATM hardware consists of an E1 ATM applique connected to an HCAP or HCAP-T main assembly. The E1 ATM hardware performs the same functions as the ANSI ATM hardware, with these exceptions:

• support for the E1, ATM, and AAL5CP layers of the ATM high-speed signaling link protocol stack as indicated in Figure C-5.
• E1 layer support
  • Support CRC-4
  • Support Si and Sn insertion in Channel 0
  • Support E1 defect reporting:
    • LOS
    • LOF
    • LCD
• OAM F5 cell support - only end-to-end OAM F5 cells for a VCC are required to be supported

E1 Overview

This section provides an overview of E1, its protocol and characteristics.

Frame Structure

E1 is a 2.048 Mbps interface. It has a frame structure of 256 bits that is repeated at a rate of 8 KHz. The 256-bit frame is broken into 32 eight-bit time timeslots, numbered 0 to 31, as shown in Figure C-6. Timeslots can also be referred to as channels.

Figure C-6 E1 Frame Structure

Timeslot 0

Timeslot 0 is used for frame alignment and CRC functions. Alternating frames contain the Frame Alignment Signal (FAS), X0011011, where X is supplied from the International Usage Spare Bit information (Si). Frames without the FAS carry Si, Alarm, and Sn information. Bit 1 is set to 1 to prevent accidental emulation of the FAS.

Si is reserved for international usage. CRC-4 specified below is one specific use. If no use is specified, Si should be set to 1. Sn is a 5-bit field (value 0 – 31). ‘A’ is an alarm bit. If set, it indicates a remote alarm indication.

CRC-4

A CRC-4 multi-frame structure is shown in Figure C-7. CRC-4 uses timeslot 0 primarily to aid in frame alignment validation but can be used to monitor error performance as well. A CRC multi-frame consists of timeslot 0 information from 16 consecutive frames. Each CRC-4 multi-frame is divided into 2 eight-frame sub-multi-frames (SMF).

Bit 1 is used to carry 3 different pieces of information:

• A multi-frame alignment word is a repeating 6-bit code (001011) that is located in frames 1,3,5,7,9, and 11.
• A 4-bit CRC code word (C1, C2, C3, C4), which is a data check on the previous 8 E1 frames. The check covers the data for all 32 timeslots. (8 frames * 256 bits/frame = 2048 bits) Each SMF has its own code word. The code word for SMF I is in frames 0, 2, 4 and 6. The code word for SMF II is in frames 8, 10, 12, and 14.
• E (CRC-4 Error indication) bits, present in frames 13 and 15.

The Alarm Indication Signal is received in Channel 0, Bit 3 of the non-alignment frame. If this bit is set, it indicates a Remote Alarm Indication. As with the ANSI ATM, this condition is ignored.

Bits 2 through 8 follow the standard E1 frame structure.

If CRC-4 in on, the provisioned Si information is not used. Instead, bit 0 is used for CRC4 information, CRC4 error reporting, and for multiframe alignment (see Figure C-7).

Figure C-7 CRC-4 Multiframe Structure

ATM Mapping into E1

Data channels 1 – 15 and 17 - 31 carries the data for a single ATM channel, as shown in Figure C-8. Note that the ATM cell size does not map directly over the E1 frame format, so the ATM cell can start in any data channel. The data is octet-aligned.

Figure C-8 ATM Cell Mapping into E1 Frames

ATM Driver

The ATM driver is a software module, residing as part of the ATMANSI or ATMITU applications, that provides the code required to interface between the AATM hardware and the SSCOP layer and ATM Layer Management interfaces. The primary functions of the driver include:

• initialization and control of the AATM hardware
• interface between AATM hardware signals and data structures and the relevant messages/data to/from the SSCOP and ATM Layer Management layers
• provide the DIMM buffer management interface required for the AATM hardware for user data received and transmitted (that is, provide free receive buffer lists for the AATM hardware after grabbing buffers from DIMM mgmt, provide information detailing where to transmit user data from, etc.)
• some of the functions listed above in the AATM hardware section (such as providing separate ‘receive channels’ for OAM F5 vs. user data cells to/from higher levels) may actually be performed in this layer based on the actual ATM hardware solution selected
• the only type of AAL service needed is for AAL Type 5 (AAL5)
• the AATM hardware and ATM driver together make up the common part of the SAAL layer, also known as the Common Part Convergence Sublayer (CPCS) or AAL5CP, when the AAL type in question is AAL5.

E1 ATM Driver

The E1 ATM driver is a software module that provides the interface between the E1 ATM hardware, the SSCOP layer, and ATM Layer Management Module. The E1 ATM driver exists only in the ATMITU application. The basic structure is based upon the ANSI ATM driver present in the ATMANSI application. The primary changes to the existing ANSI ATM driver include:

• initialization and control of the new E1 ATM appliqué.
• remove T1 support of 4 Kbps data link (BOCs, including performance reports and T1 loopback tests)
• verify correct E1 ATM appliqué is installed and reboot if not

SSCOP

The primary task of the SSCOP (Service Specific Connection Oriented Protocol) is to provide assured data delivery between AAL connection endpoints. The SSCOP is 1 of 2 parts (the other being the SSCF) of the Service Specific part of the SAAL layer (also known as the SSCS, the Service Specific Convergence Sublayer of the SAAL). The other part of the SAAL Layer is the CPCS (which was just mentioned in the ATM driver). Breaking the SSCS into 2 sublayers allows a common connection oriented protocol with error recovery (the SSCOP) to provide a generic reliable data transfer service for different AAL interfaces defined by different SSCF layers. The primary functions of the SSCOP layer include:

• transfer of user data with sequence integrity
• error correction by selective retransmission
• flow control
• connection control
• error reporting to layer management
• connection maintenance in the prolonged absence of data transfer
• local data retrieval by the user of the SSCOP
• error detection of protocol control information
• status reporting

SSCF

The primary task of the SSCF (Service Specific Coordination Function) is to map the services provided by the lower layers of the SAAL to the needs of a specific higher layer user. For the ATM high-speed signaling link, the higher layer user is the MTP-3 protocol.

• maps signals/primitives from MTP-3 (SSCF user) to SSCOP, and vice versa.
• performs local retrieve function, required by the changeover order.
• flow control on transmit direction (SSCF notifies the user of congestion levels)
• maintains and controls the link status
• generates necessary reports to ATM Layer Management (primarily the cause for the release of the SSCOP connection)
• implements some SSCF to SSCF, peer to peer messages primarily related to connection establishment and release
• controls local and remote processor outage and recovery
• controls the alignment procedure

For an E1 ATM high-speed signaling link, the link proving default values are significantly different compared to an ANSI ATM high-speed signaling link. Table C-1 illustrates the different link proving values.

Table C-1 Link Proving Differences Between ITU and ANSI

CHG-ATM-LPS Parameter Name	Description	E1 ATM Default Values	ANSI ATM Default Values
N1	Number of PDUs sent during link proving	1000	64552
TmrT2	Time to attempt link proving	30 sec	120 sec
maxnrp	Maximum number of retransmitted PDUs during proving	0	1
TmrT3	Time between proving PDUs	925 sec	925 sec

The time required for normal ANSI proving is approximately 60 seconds (925 sec/pdu * 64552 PDUs = 60 seconds). This time is greater than TmrT2 value for an E1 ATM high-speed signaling link (30 seconds), so a link with E1 ATM defaults would have gone out of service before a link with ANSI ATM defaults finishes proving. Thus, great care must be taken to ensure that compatible proving numbers are assigned to a signaling link.

ATM and SAAL Layer Management Interfaces

The primary task of the ATM and SAAL layer management layers is to map requests and indications between the system management for the EAGLE and the individual ATM, AAL5CP, SSCOP, and SSCF layers. This functionality is actually achieved using two management modules, which both interface to the system management.

ATM Layer Management

ATM layer management is achieved with the ATMM (ATM layer management module). The ATMM provides a supporting role for system management functions which include fault, performance, configuration, security and resource management functions. It is the job of the system management to coordinate with different layers locally to perform all tasks associated with these functions. The ATMM entity uses two types of interactions with the ATM entity to perform its functions. The first type of interaction is for the exchange of info between the ATM and ATMM entity. The second type of interaction is for peer to peer communication between ATMM entities (between the two nodes on both ends of the high-speed signaling link). This second interaction is achieved by sending and receiving and processing OAM F5 cells in the ATM high-speed signaling link implementation. The primary functions provided by the ATMM for an ANSI ATM high-speed signaling link include:

• OAM F5 fault management: includes alarm surveillance, loopback using OAM cells, and continuity check
• OAM F5 performance management: includes activation and deactivation of performance monitoring, forward and backward monitoring and reporting of performance to system management.

  Note:

  The general ATMM layer is capable of performing performance management functionality. The ATMM layer implemented by ATM high-speed signaling link does not support this capability.

The primary functions provided by the ATMM for an E1 ATM high-speed signaling link include only OAM F5 fault management: loopback by OAM cells. All other forms of OAM F5 management and OAM F5 performance management are not supported.

SAAL Layer Management

The SAAL layer management includes interfaces to and from AAL5CP, SSCOP, SSCF, and system management. SAAL layer management supports the following functions:

• error processing for these layers
• error monitoring for in-service links
• detection of excessive time with no credit
• detection of closely spaced SSCOP recoveries
• measurements
• duration of presence in the in-service state
• signaling link failures
• signaling link restoration
• handling of processor outage conditions
• management of signaling link proving