2.1 NMS Hardware and Software

2.1.1 CG Hardware

2.2 Natural Access Software

2.2.1 Natural Access Development Environment

2.2.2 NMS OAM

NMS OAM Configuration Files

2.2.3 Runtime Software

2.2.4 Trunk Control Programs

2.2.5 Platform Support for DLCP System Overview

2.3 Aztek Protocol Stacks

2.3.1 Access303 and Exchange303 Protocol Software

2.3.2 AV5 Protocol Software

2.1 NMS Hardware and Software

The Platform support for DLCP environment includes the following NMS hardware and software:

• CG board hardware

• Natural Access software

• Platform Support for DLCP software (including the NMS V5 and NMS GR303 libraries).

• C++ development environment

In addition, Platform Support for DLCP requires a V5.2 or GR-303 stack through which the application can perform DLCP functions. This chapter describes the Aztek Access303, Exchange303, and AV5 protocol stacks which implement the RDT, IDT, and AN sides of the GR-303 and V5.2 interfaces.

2.1.1 CG Hardware

The NMS Convergence Generation (CG) board family includes both PCI (CG 6000) and Compact PCI (CG 6000C) boards that provide the following features per slot:

• 4 T1 or E1 (75 or 120 ohm) trunk interfaces that provide up to 120 universal ports of voice and fax data.

• Up to 3 HDLC controllers on each T1 or E1 digital trunk interface.

• CG 6000C boards provide full support for the H.110 bus specification, which enables the boards to share data with other boards on the H.110 bus. CG 6000 boards fully support the H.100 bus specification (within the H.100 architecture), which enables the boards to share data with other boards on the H.100 bus.

• Telephony bus switching to provide a total of 256 full duplex connections between local devices and the CT bus. Switch connections are allowed between local devices and are non-blocking.

• Two 10/100 Base-T Ethernet connections for Fast Ethernet connectivity to IP networks.

• 233 MHz SA110 Intel StrongARM processor with 32 MB of SDRAM.

• High performance digital signal processors (DSPs) that provide 100K words of SRAM.

CG 6000 and CG 6000C boards accommodate up to 32 DSP cores that provide resources for universal IP gateway ports.

The CG board family is supported by the NMS Natural Access development and runtime environment. Software for CG boards is part of the Natural Access package.

2.2 Natural Access Software

CG family boards require the following Natural Access software components:

• Natural Access development environment that provides services for performing call control, system configuration, media processing, and other functions.

• NMS OAM software that configures, administers, and maintains on the system.

• OAM Configuration files that describe how the board is set up and initialized.

• Runtime software and drivers for controlling CG boards.

• One or more trunk control programs (TCPs) that allow applications to communicate with the telephone network using the signaling schemes (or protocols) used on the trunk.

2.2.1 Natural Access Development Environment

Natural Access is a complete development environment for telephony applications. It provides a standard set of telephony functions grouped into logical services, each of which has a standard hardware-independent API.

The Natural Access programming environment provides the following features:

• Hardware-independent standard APIs.

• Logical services that group functions into sets.

• Standard re-configurable service parameters.

• Error trapping and tracing features.

• Resource management.

• Support for different programming models.

• Multiple operating system support.

Figure 2 shows the Natural Access architecture:

Figure 2. Natural Access Architecture

DLCP applications require the following services:

Service	Description
SWI	Switching service that provides a set of functions for controlling Multi-Vendor Integration Protocol (MVIP) switch blocks on MVIP and H.100/H.110 compliant switching devices. The switch block is controlled by the Switching service functions to make or break connections, send patterns, sample data, query, reset, configure, and run diagnostics on different parts of the MVIP switching device. This service is optional for the NMS GR303 and NMS V5 libraries, though required by NMS GR303 and NMS V5 applications.
ADI	Media and call control service for NMS CG and AG families of boards. This service is optional for the NMS GR303 and NMS V5 libraries, though required by NMS GR303 applications to perform CAS ABCD robbed-bit signaling.

When installing Natural Access software, install the services listed above. In addition, if your application requires functionality provided by any other Natural Access services, you must also install and initialize these services.

2.2.2 NMS OAM

NMS OAM is an extension to Natural Access which configures, administers, and maintains board and system resources. These resources include hardware components (such as CG boards) and low-level board management software modules (such as the Hot Swap process). You can use NMS OAM to perform the following tasks:

• Create, edit, delete, and query the configuration of a component

• Start (boot), stop (shut down), and test a component

• Receive error and event notifications from components

NMS OAM maintains a database containing records of configuration information for each component.

Information within this configuration database consists of parameters and values, expressed as a keyword name/value pair (for example, Encoding = MuLaw). You can query the NMS OAM database for keyword values for any component. Keywords and values can be added, modified or deleted.

Use the oamsys utility to initialize your boards based on the information in the configuration files. oamsys transfers all software modules specified in the system configuration file (and the board keyword files referenced by it) to the boards on the system. oamsys also performs other configuration tasks as needed. In addition, NMS OAM provides the following utilities:

• oammon allows you to monitor boards for errors and other events

• oamcfg allows you to change system information or board parameters while the system is running.

Figure 3 illustrates how NMS OAM maintains configuration information for NMS hardware and software components:

Figure 3. NMS OAM Components

For more information about NMS OAM and NMS OAM utilities, refer to the NMS OAM System User's Manual.

NMS OAM Configuration Files

An NMS OAM system configuration file and the board keyword files it references provide information that tell the oamsys configuration program how to configure a board. When you set up your system, edit these files to specify configuration information for all boards in your system with configuration files and board keyword files.

Define the following information:

• Whether or not a board performs MVIP switching

• Which board is the MVIP clock master

• Which software modules to transfer to the CG board's memory on startup

• Configuration settings for the board's T1 or E1 interfaces

• Additional configuration information such as DSP resource management.

Several sample files are included with Platform Support for DLCP software. These sample files provide configuration keywords for systems that use different board sets (CG 6000 or CG 6000C). Chapter 3 provides additional information about how to customize these files to specify settings appropriate for your system environment.

2.2.3 Runtime Software

CG runtime software consists of runfiles (also known as Downloadable Modules or DLMs), a core file stored in non-volatile memory (flash memory), and DSP files. The runfile is the basic low-level software which a CG board requires to operate. DSP files enable CG board on-board DSPs to perform certain tasks such as DTMF signaling, voice recording, voice playback, and CAS robbed-bit signaling.

Several runfiles and DSP files are installed with Natural Access software. Each board's OAM board keyword file specifies which files to transfer to the board's on-board memory when the board is booted.

2.2.4 Trunk Control Programs

In order to provide call-control capabilities on PSTN ports, applications associate a telephony protocol with each port. On CG boards, telephony protocols are supported as Trunk Control Programs (TCPs), that are loaded when the board is initialized. When applications start a protocol, TCPs enable the application to use the call control functions associated with that protocol. NMS provides TCPs for most standard telephone line interfaces, and also provides a NOCC (No Call Control) TCP for applications that do not perform call control or that manage line interfaces manually. For more information about Natural Access TCP software, refer to the NMS CAS for Natural Call Control Developer's Manual.

2.2.5 Platform Support for DLCP System Overview

DLCP (GR-303 or V5) systems are based on several components. CG boards provide a physical layer hardware platform. Platform Support for DLCP software provides GR-303 and V5.2 protocol-specific interfaces so that NMS hardware can support protocol Layer 1 functionality. Applications also use Aztek's Access303, Exchange303, or AV5 protocol stack software to integrate GR-303 or V5.2 compliant upper layer interfaces. Figure 4 provides an overview of the DLCP system environment:

Figure 4. Platform Support for DLCP (GR-303 or V5.2) System Architecture

To perform CG board switching or media or signaling processing tasks, applications can invoke functions from the SWI service. For example, GR-303 and V5 protocols require dynamic switching between timeslots on a per-call basis. Applications can do this by using functions from the SWI or PPX services. In addition, the GR-303 protocol defines a 16-state robbed-bit signaling option for transmitting call-processing messages between the RDT and the IDT. Applications must use the ADI service to control CAS robbed-bit signaling required by the GR-303 protocol.

The application may also need other NMS software, such as ISDN protocol software to terminate ISDN calls, or NMS Fusion software to implement VoIP gateway functionality. The system may also use additional NMS boards to perform as ISDN PRI or BRI line cards.

2.3 Aztek Protocol Stacks

Aztek protocol software implements the upper layers of the V5.2 and GR-303 protocols. Aztek provides the following products that can be obtained separately:

• AV5 (V5.2 protocol) software

• Access303 (RDT side of the GR-303 protocol) and Exchange303 (IDT side of the GR-303 protocol) software

The sections that follow describe the two protocol stacks in more detail.

2.3.1 Access303 and Exchange303 Protocol Software

Aztek Access303 and Exchange303 software support the Remote Digital Terminal (RDT) and Integrated Digital Terminal (IDT) sides of a GR-303 interface, as defined in GR-303-CORE and GR-303-IMD. This software includes the Time Slot Management Channel (TMC) and Link Access Procedures for the D-channel (LAPD) protocols.

In addition, Access303 and Exchange303 provide Embedded Operations Channel (EOC) functions of a Convergence Layer, a Remote Operations Service Element (ROSE) layer, Common Management Interface Service Layer (CMISE) and Path Protection functionality. Access303 and Exchange303 also include the AIM-303 (aim303), an integration tool for the protocol software.

Access303 and Exchange303 are based on a layered software architecture. Layer 2 supports the LAPD protocol. When communicating between an RDT and an IDT, LAPD sends messages to, or receives messages from, the physical layer (Layer 1) provided by the application. When communicating with the rest of the RDT or IDT application, LAPD exchanges messages with the upper layer.

Access303 meets GR-303-CORE and GR-303-IMD specifications and the
GR-303 interface specifications for switch vendors. Because Access303 and Exchange303 are independent from the underlying network architecture, applications that integrate with the Access303 and Exchange303 protocol stacks can be based on Digital Loop Carrier (DLC), Hybrid Fiber Coax (HFC), Wireless Local Loop (WLL), Voice Over Internet Protocol (VOIP), or any other access network architecture.

The Access303 and Exchange303 products are provided as source code that can be ported to a variety of hardware and operating system platforms for which an ANSI C compiler is available. The Access303 and Exchange303 stacks can be built in either library or an executable form.

2.3.2 AV5 Protocol Software

Aztek AV5 software implements the Access Network (AN) end of an ETSI V5 protocol. AV5 includes five Layer 3 protocols, one Layer 2 protocol and Layer Management. Supported Layer 3 protocols include:

Protocol	Description
PSTN	Supports signaling for analog ports.
BCC	Supports dynamic timeslot assignment and therefore provides concentration.
Control	Supports synchronized application of provisioning data, port blocking, and restart.
Link control	Provides link blocking and coordination of link numbering.
Protection switching	Supports standby protection of the signaling channels.

AV5 supports the Layer 2 protocol LAPV5, which is an LAPD-like protocol specifically adapted for V5 interfaces. AV5 also includes frame relay capabilities for ISDN D-channels at Layer 2. The Layer Management Entity supports a set of management capabilities including datalink management, E1 link management, protection management, and the provisioned database capabilities. These management features allow higher level management of the Layer 3 protocol entities, and thus provide for simplified system management.

AV5 is a complete implementation of the V5.1 and V5.2 protocol, with additional features and tools, that has been proven compliant with industry standards through testing with the ETSI Abstract Test Suite (ATS).

AV5 interfaces with an AN system in the following areas:

• An RTOS abstraction interface for which Aztek provides sample code.

• A PSTN nationalization sample task.

• APIs for connections through a TSI.

• APIs with Layer 1 and Layer 1 Management functions.

• APIs with system management.

The AV5 product is provided as source code that can be ported to a variety of hardware and operating system platforms for which an ANSI C compiler is available. The AV5 stack can be built as either a library or an executable.