Table of Contents NMS Glossary Previous Page Next Page Version


Chapter 1

Introduction


1.1 Introduction
1.2 Overview
1.2.1 Terminology
1.3 Software Architecture
1.4 Virtual Port Library
1.4.1 Virtual Port Configuration API
1.4.2 Virtual Port Data Transfer API
1.5 PSTN Interface Adapters
1.6 Switching Virtual Port Data
1.6.1 Circuit Switching
1.6.2 Dedicated Data Channels

1.1 IntroductionTop of Page

The TX Series Virtual Port Developer's Reference Manual describes functions (and associated packet formats) used to set up host-based virtual port communication with TX board resources.

1.2 OverviewTop of Page

Time division multiplexing (TDM) is a method of transmitting a number of signals (voice, data, or video) over a single communications medium. Virtual ports provide a way to control time division multiplexing on streams of data that pass through network interfaces and the MVIP bus. Virtual ports allow applications to receive a subset of the signal data carried over a shared resource (such as the MVIP bus). By assigning different addresses to each virtual port attached to a given resource, multiple software applications are able to seamlessly communicate across a single channel.

This manual describes the Virtual Port APIs (and associated packet formats) used to accomplish host-based virtual port communication. The communication processor (CP) operating system (or KERNEL) provides virtual port access for HDLC framed transfers and Ethernet transfers. HDLC framing can be applied to both physical ports (those routed to daughter cards/pods) and MVIP ports (those mapped to the MVIP bus).

This manual also provides an overview of the software modules and development tools available for building applications and systems based on the TX board TDM processing facilities.

1.2.1 TerminologyTop of Page

The following table defines specialized terms used to describe components of the TX series board environment and virtual port software architecture:

This term...

Refers to the following...

68360 processor

Each 68360 contains 4 serial communication controllers. On TX 2000 board communication processors, one 68360 is designated as the main 68360, acting as both the main processor (68000 class) and communication controller. A second (optional) 68360 is the slave 68360, utilized only for its additional serial communication controllers. Each 68360 also contains a flexible serial interface (SI), including a timeslot assigner, which allows the serial communication controllers to be used for both TDM streams and other serial interfaces, such as those provided by the V.35, V.24/RS-232, and Ethernet adapters.

Channel

Channels are the individual physical communication paths from the TX board to other endpoints. Some physical interfaces, such as the MVIP and T1/E1 interfaces, support multiple channels. Others, such as the serial and Ethernet interfaces, support a single channel. Channels generally correspond to an individual 68360 (main or slave) serial communication controller, although with the QUICC-32 a single serial communication controller can be used to provide up to 32 channels.

FMIC

The Flexible MVIP Interface Circuit (FMIC) provides the digital timeslot switch and MVIP bus interface.

Hyperchannel

TDM timeslots can be grouped together to form higher rate channels called hyperchannels. For example, 6 full-duplex 64 Kbps timeslots can be grouped together to form a single 384 Kbps full-duplex channel. On a TX board, a hyperchannel is configured by specifying a range of timeslots (they must be contiguous). Since a hyperchannel corresponds to a single communication path and a single protocol instance (at the link layer), it is really just a channel; for the rest of this document, channels and hyperchannels will not be differentiated.

QUICC-32 mode

TX boards support a hardware option that replaces a standard 360 based processor chip with a QUICC-32 capable 360, allowing a single communications controller to operate as 32 independent channels. TX board configurations can include up to 2 360s operating in QUICC-32 mode (yielding a maximum of 64 MVIP channels). These channels can be configured to correspond to a single 64 (or 56) Kb MVIP timeslot or an MVIP hyperchannel (up to 1 megabit).

To implement QUICC-32 functionality, the KERNEL takes over control of serial communication controllers 2-4, making them unavailable for standard resource definitions. Serial communication controller 1 remains available (usually for Ethernet).

Resource definitions for QUICC-32 configurations are identical to those for standard definitions, except that the serial communication controller number is not specified (see Appendix B). This removes the need for systems engineers to have a knowledge of the KERNEL's internal mapping schemes. Once QUICC-32 resources have been defined, all other channel-related functions are performed identically to the standard 360 mode.

Resource

Resources are logical entities which define paths, or protocol instances, between TX series software entities and peers at other endpoints. For MVIP and T1/E1 resources, there is an associated serial communication controller (the main entity manipulated by TX series communication software) per resource. Resources are mapped onto physical channels by a combination of system rules and system configuration as part of the TX board operating system (KERNEL) boot process. There are several different types of ports, generally corresponding to the different physical interface types. Certain link-level protocols may provide additional multiplexing capability such that a single physical channel can be used to provide many virtual ports.

After the TX board has completed the boot phase, all resources are defined as non-shared, indicating that software attaching to the resource has total ownership of the resource. By using the Virtual Port API, host applications can define new shared resources (or redefine non-shared resources that are not in use).

Stream

Streams are groups of channels combined on a single set of signals through time division multiplexing (TDM). Each T1 or E1 line is a TDM stream; the MVIP bus is actually 8 TDM streams of 32 channels each. Internally, TX boards support two 2.048 Mbps TDM streams, called local streams 0 and 2, which can be connected to 68360 (main or slave) for protocol processing. The T1/E1 streams (which use local streams 1 and 3 internally) can be directly connected to the TX board's local streams 0 and 2. The FMIC chip on the MVIP daughtercard can be used to map various combinations of MVIP channels and/or T1/E1 channels onto the TX board's local streams 0 and 2.

Timeslot

Each channel on a TDM stream is also called a timeslot. On TX boards, each time-slot on a TDM stream forms a 64 Kbps DS0 channel. Thus, a pair of timeslots, one in each direction, forms a full-duplex 64 Kbps DS0 channel.

Virtual Port

Virtual ports control the connections between TX series application software and KERNEL resources. A virtual port can be assigned to a shared or non-shared resource. When an application activates a virtual port that is assigned to a non-shared resource, that application receives all data received through the resource. Activating a virtual port associated with a shared resource allows the application to receive a subset of the entire data stream being received through the resource. By assigning a different receive address set to each virtual port attached to a given resource, multiple software applications are able to seamlessly communicate across a single channel.

1.3 Software ArchitectureTop of Page

The TX series host application development environment consists of a series of API libraries that enable the application programmer to configure and control the various protocol engines loaded on TX boards. This manual describes the Virtual Port Configuration and Data Transfer API.

chap1a.gif

Figure 1. TX Series Software Architecture


Note:  Always use the structure packing compile option when compiling source code using these libraries and APIs.

1.4 Virtual Port LibraryTop of Page

The Virtual Port API provides a means of configuring and controlling virtual ports within the TX board environment. The Virtual Port API is platform independent and can be used on any host system supported for TX board development. All access to the communication processor is handled by calls to the CPI library.

The Virtual Port API consists of two major sections:

These APIs are found in the vpdapi library module. Access to this API is defined by the include file vpdapi.h, and all literal/structure definitions may be found in vpdtype.h.

1.4.1 Virtual Port Configuration APITop of Page

TX boards use a high-speed dual port static RAM and a memory mapped control and status register to facilitate communications between the board communications processors and the PC. The Virtual Port Configuration API includes functions for:

  1. Building dual port RAM packets

    
    
  2. Issuing requests to the communication processor

    
    
  3. Waiting for responses

    
    
  4. Matching requests with responses

    
    
  5. Returning the results of the exchange

Messages used to perform virtual port configuration are described in the API include files. The most common method of performing virtual port configuration is to use the vpdcfg utility to configure virtual ports according to a configuration script file.

Note: If you do not want to use the Virtual Port Configuration API, you can use direct dual port RAM packets instead. The application is responsible for performing request/response matching. The packet protocol for the Virtual Port Configuration API is described in Chapter 6.

1.4.2 Virtual Port Data Transfer APITop of Page

The Virtual Port Data Transfer API is used to assist in the formation of dual port RAM packets. Each function takes a dual port RAM packet as input (as well as a set of function-specific parameters). The API function fills in the dual port RAM packet with all constant indicators for the type of request indicated. The input parameters are then placed into the dual port RAM packet and the packet is issued to the communication processor.

The Data Transfer API does not wait for responses. All responses are received asynchronously. The application must match requests with responses and verify fields in the received packets.

Note: One alternative to using the Virtual Port Data Transfer API, is performing raw dual port RAM packet exchange. This allows developers to send packets directly (by passing the Data Transfer API). Packet formats are described in Chapter 6.

1.5 PSTN Interface AdaptersTop of Page

The TX board communication processors support the following (optional) interfaces for transmitting and receiving digital data, audio, and video signals to and from public switched telephone networks:
Adapter

Function

MVIP Bus interface

Gives the TX boards board access to the MVIP bus through a non-blocking digital timeslot switch. The MVIP bus adapter is an enhanced MVIP switching compliant device that can be used to make connections between the MVIP bus, optional T1/E1 interfaces, and on-board serial communication controllers.

The MVIP bus adapter can be used by itself to allow the TX board to perform protocol processing on streams routed from other network interface boards through the MVIP bus or in conjunction with the dual T1/E1 adapters, as described in the following section (use of the dual T1/E1 adapters requires use of the MVIP bus adapter).

Dual T1 interface

Provides a flexible interface for terminating T1 circuits for protocol processing by the TX board serial communication controllers, or for switching to/from other boards through the MVIP bus adapter. It is ideally suited for data and common channel signaling (SS7) applications.

The dual T1 adapter provides a DSX-1 type interface. It can be connected to the public switched telephone network through an external channel service unit (CSU) or may be directly connected to other local equipment providing a compatible interface. In the case of a direct local connection, the TX board T1 lines can be independently configured as either the loop master (timing source of the circuit) or as the loop slave (deriving clocking from the circuit). The T1 lines can also be configured with different framing and/or line coding options if desired.

Dual E1 interface

Provides two E1 (CEPT) compliant line interfaces. Like the T1 adapter, it can be used in conjunction with the TX board protocol processing capabilities and Natural MicroSystems' protocol processing software (such as the SS7 stack) to create powerful data and/or common channel signaling applications.

The E1 lines can be independently configured for standard FAS, CRC4, and/or CAS (channel associated signaling) framing formats and AMI or HDB3 line coding formats. Each line can be optionally configured as the timing source (loop master) of the circuit or as the loop slave, deriving clocking from the circuit.

1.6 Switching Virtual Port DataTop of Page

The following sections describe switching virtual port data.

1.6.1 Circuit SwitchingTop of Page

The TX series circuit switching service provides MVIP enhanced switching between any pair of timeslots on the T1/E1 and/or MVIP interfaces. This includes connections between any MVIP bus timeslot and any T1/E1 timeslot, between any two MVIP timeslots, and between any two T1/E1 timeslots on the same or different T1 interfaces (without using any MVIP bus timeslots).

1.6.2 Dedicated Data ChannelsTop of Page

The TX series circuit switching service allows timeslots from either T1/E1 interfaces or the MVIP bus to be nailed-up to serial communication controllers on the TX board main or slave 68360 processors to form dedicated data channels. These channels can be individual 56 or 64 Kbps Ds0 channels, or ranges of timeslots may be grouped together to form higher bandwidth hyperchannels. Other NMS communication software products can be configured to operate on these channels.

Nailed-up timeslots are configured with the Virtual Port Configuration API or with the Virtual Port Configuration utility (vpdcfg). Although these connections are connected to specific 68360 serial communication controllers and are not affected by the TX board circuit switching operation, they may be switched dynamically if they are not being used by an application. However, the number of timeslots assigned to a given resource must remain the same, (the specific timeslots of a resource are switchable), but the total number of timeslots must remain fixed.

Circuit switched and nailed-up timeslots can be mixed on the same T1/E1 interface and on the MVIP bus. For example, a single T1 interface can consist of a single timeslot nailed up to a 68360 serial communication controller carrying SS7 (out of band) signaling data (processed by the NMS SS7 software product) and 23 circuit switched voice/data channels under control of an application on the host PC. The host application instructs the TX board to make connections between the T1/E1 timeslots and the MVIP bus (or other T1/E1 timeslots) based on signaling messages received on the SS7 data channel.

Note: When a configuration consists of both circuit switched and nailed-up timeslots, certain application operations, such as resetting the entire switch block, have a slightly different meaning. These operations are performed only on the circuit switched timeslots (where applicable) - the nailed-up timeslots remain intact.



Table of Contents NMS Glossary Previous Page Next Page Version


Want to send us feedback on our documentation? Email: Tech_Pubs@nmss.com
Copyright © 2000, Natural MicroSystems, Inc. All rights reserved.