Frequently
Asked Questions
Trunk
Management Software
What
is NComm's Trunk Management Software?
What
advantage do I have with NComm TMS rather than developing this
software in-house?
Does
the TMS employ an Application Programmers Interface (API)?
Are
multiple
span
devices
supported?
What
framer devices are supported?
Is
the framer device driver extra?
How portable is my application if I want to change platforms?
What
Operating Systems are supported?
What
is the typical porting time?
What
processor is the software written for?
What
kind of system resources does the TMS consume?
Does
the license include source code?
What
is the source code written in?
Does
NComm offer trial code?
What
support is included in the license?
Is
extended support offered?
What
capabilities are in your T1/E1 TMS modules?
What
robbed bit signaling models are supported?
What
capabilities are in your T3 and E3 TMS modules?
What
capabilities are in your SONET TMS modules?
What support does
NComm have for protection switching?
Does
NComm have any other software offerings?
Does
NComm have any hardware offerings?
Who
is NComm?
Do
you do consulting work?
NComm's
Trunk Management Software, or TMS, is a completely functional
suite of T1/E1, and T3 software providing configuration, alarm,
maintenance/performance monitoring, loopback activation, Robbed-Bit
Signaling (T1) and Channel-Associated Signaling (E1), functionality.
The TMS sits between the developers product and the framer driver
below. It does not deal with the data payload, but handles the
control, monitoring and reporting required to keep the trunk
operating as effectively as possible and in a standard compliant
manner.
NComm's
TMS is available for T1, E1 and T3. We have recently released
a T1/E1 LIU package when combined with the T3 TMS provides full
functionality for an M13 mux application. A variety of
framer drivers are ready to ship now.
Top
With
NComm's TMS software, you collapse your T1/E1/T3 development
schedule from the better part of a year to just a few days, thus
gaining time-to-market. You also spend less money and conserve
scarce development resources.
First
time development of T1, E1 or T3 standard compliant programming
in-house takes about 2 staff-years and 9-12 months of elapsed
time. When you are done, you have nothing that differentiates
your product. You just have something that works. You also have
consumed more engineering expenses than going with NComm and
have lost a couple of staff-years of effort that could have been
applied to adding value to your product. Further, you added another
branch of development activity that probably delayed your product
release and added risk to the entire product in terms of the
software being standards compliant and even functional.
Top
Yes,
there are two API layers, each with three function calls. The
first API layer is between the customer's application and the
TMS software. The second API layer is between the TMS software
and the framer device driver. Usually, the developer will only
need to work with the application API layer.
Top
Yes. The
TMS APIs support single and multiple span devices. Part
of the TMS initialization process binds the logical span number
to the particular device and the span offset in the device. Thus,
the TMS codes allows multi-span framers as well as framers from
different vendors to operate with a unified application layer
API.
Top
Most
of the Dallas, Infineon, PMC and Agere as well as several other
T1, E,1 T3, E3 and SONET/SDH devices are currently supported.
If a specific device is not currently supported, NComm will
develop a new device driver within 8 weeks of order (10 weeks
for SONET/SDH).
Top
No,
a framer device driver for the customer's specific framer device
is included with the TMS package at no additional charge. Additional
drivers are available for an additional license fee.
Top
NComm's
TMS is architected to make the framer device transparent to
the customer application. The device driver acts as the "shock
absorber" and takes care of hardware nuances. Both the TMS
and customer application layers are totally portable to another
platform simply by changing the framer device driver. We aim
for 100% preservation of the investment the user makes to their
software.
Top
The
TMS package comes already ported to Linux, VxWorks, OSE, and
Nucleus Plus real time operating systems. It can also run under
a simple visitation loop, although this is not recommended.
The
NComm TMS software is designed to be O/S-independent. The
TMS package is easily ported to most real time operating systems. The
porting issues are generally restricted to only one header file
containing a few macros that resolve to operating system kernel
calls. A porting guide is available to ease migration
to other operating systems if the customer wishes to perform
their own port.
Top
Provided
that your hardware is debugged, porting time is typically a few
days. About a third of our users are up in less that a single
day.
Top
The
TMS software is standard ANSI C-code, and is therefore processor
independent. NComm tests all software on a Motorola 860 platform
with the customer's specific framer device prior to release.
Top
The
following table illustrates CPU bandwidth consumption for various
TMS configurations; these are standard Dhrystone Ver 2.1 MIPs
measured on an MPC860 or
an MPC8260 platform. Note
that resource figures are similar across processors with framer
devices that do not utilize indirect register access.
TMS
Package |
CPU
Utilization*
(w/
Signaling) |
CPU
Utilization*
(w/o
Signaling) |
(ROM)
TEXT/CODE* |
(RAM)
DATA/BSS* |
Max
Allocated Mem per Span |
T1 |
1.09
MIP |
0.17
MIP |
168
K |
11 K |
83 K |
E1 |
1.48
MIP |
0.24
MIP |
136
K |
7 K |
71 K |
T3 |
0.33
MIP # |
119
K |
4 K |
130
K |
E3 |
0.33
MIP # |
111
K |
4 K |
77 K |
| SONET/SDH -
Call for specific case |
*
MIPs are conservative estimates; Text/Code is per system; Data/BSS
is per line or span; T1/E1 Data/BSS is less than the sum; E3
MIPS estimated
#
Signaling is not applicable for T3, E3 or SONET/SDH
Top
Source
code is included in the software deliverable. The user is free
to modify the source code with the caveat that modification
would restrict NComm support. The license is for distribution
of compiled object code embedded in a product.
Top
The
source code is written in standard ANSI-C. No assembly code is
used.
Top
No.
NComm does offer a 30 day money back guarantee that allows a
developer to actually use the software and return it for a full
refund if not satisfied.
Top
60
days of implementation support to answer questions about TMS
is included. In addition, a day of training is provided
at NComm's offices.
Top
Yes,
extended support is available for 12% of the license price
per year. This entitles the user to bug fixes, enhancements
and reasonable telephone support. If issues are found in the
users code, NComm will fix the users version of code if requested
rather than force the user to move to a new code base.
Top
· Configuration
Manager Module (CMM) - Configuration for the T1/E1 span,
and for other modules purchased
Ø Line
Encoding (AMI, B8ZS, HDB3)
Ø Line
Framing Format
§ T1: D4-Super
Frame or Extended Super Frame
§ E1: Multiframe
Non-multiframe
CRC
Non-CRC
Ø Line
Build-Out (Short haul/Long haul w/ distance parameters)
Ø Alarm
integration including programmable integration timers
Ø Selection
of clear channel, idle channel, and/or signaling model. Selectable
on a per voice channel basis.
Ø Selection
of user side or network side for the interface
Ø Configuration
of addresses for maintenance protocols
Ø Selection
of remote, local, payload, and diagnostic loopbacks under application
control
· Alarm
Manager Module (AMM)
Ø Standards
compliant detection, declaration, and clearing of all alarm conditions
per T1.231
Ø Programmable
alarm integration timers for OOF, LOS, AIS, and RAI. Standards
compliant responses to far-end alarm conditions as per T1.231
Ø The
E1 alarm capabilities will meet standards per I.431, G.732, ETSI
300-233
· Maintenance
Manager Module (MMM)
Ø Manages
and responds to the Facility Data Link (FDL) per TR-54016
Ø Bit
Oriented Message (BOM/BOC) handling per T1.403
Ø Programmable
Loop Back codes
Ø In
band and out of band Loop Up and Loop Down code reception and
transmission
Ø 1
second performance report collection and transmission per T1.403
Ø 96,
15 minute performance data bucket collection and transmission
for the Near End per TR-54016
Ø Responding
to and transmitting 15 minute performance data bucket over the
FDL for the Near End per TR-54016
Ø Far
End performance data collection in 96, 15 minute buckets and
24-hour summary based upon receipt of T1.403 PRMs from the far
end.
Ø For
E1, Performance Monitoring will meet the standards per G.826
and provide a 15min/24 hour data performance database as well.
SA bit processing will conform to G.704
Ø For
E1, control of Sa, Si, and X bits.
· Signaling
Manager Module (SMM)
Ø Establishes
Robbed Bit or Channel Associated Signaling (CAS) communication
per timeslot
Ø T1
Robbed-bit signaling allows customer choice of signaling models
per T1.403 - 1999, TR-03, or GR-303-CORE-Rev3 (Tables
12-3 & 12-4). Choice may be done on a per DS0 basis
Ø E1
CAS signaling models are those defined in Q.421, Q.422 and may
be done on a per E0 basis
Ø Processes
signaling freezing and debouncing
Ø Provides
call state information such as wink, flash, on-hook, loop open,
etc. to the application layer per the selected signaling model
Ø Transmission
and reception of dial pulse digits are fully supported.
Ø Timers
associated with signaling such as wink, hook flash, and digit
on/off ratios, are programmable on a per timeslot basis
Ø TR-08/SLC-96
and T1.403 Tri-level signaling supported with external hardware
support for generation and detection of the toggling state.
Top
Currently,
all robbed bit signaling model specified in T1.403.02-1999
are supported including:
· Loop
start
· Loop
start with RLCF
· Ground
Start
· Ground
Start with RLCF
· Loop-Reverse
Battery Signaling
· Network
provided reverse battery signaling
· E & M
Signaling
· Customer-installation-provided
loop-start supervision (FXS/FXO)
· Private
line auto ring
· Ringdown
Both
SF/D4 and ESF version of these signaling models are supported. In
addition, the DS0 alarms states are provided for all ESF models.
All
6 signaling models specified by TR-08 are supported including:
· Superimposed
Ringing Multiparty
· Direct
Inward Dialing Dial Pulse Terminating
· Frequency
Selective Ringing Multiparty
· Single
Party
· Superimposed
Ringing Multiparty
· Universal
Voice Grade
The
GR-303 models from tables 12-3 and 12-4 are supported including:
· Coin
CF/DTF
· Loop
Reverse Battery - Differs from the definition in T1.403.02-1999
· Multiparty
Signaling
New
signaling models are being added. If you don't find what
you need, Contact NComm for an up to date list or your signaling
model requirements.
Top
DS3
Configuration/Alarm Manager Module (D3MM)
- Line
Encoding - B3ZS
- Line
Framing Formats - C-bit or M13 for DS3 and G.751 or G.832
for E3
- Selection
of user side or network side
- Control
and detection of AIS, IDLE, RAI conditions and AIC bit, and
REI/RDI for E3.
- Alarm
integration including programmable integration timers
- Detection
and transmission of FEAC signals and loopback codes.
- FEAC
signals automatically transmitted upon alarm declaration
according to priority scheme outlined in T1.107.
- Detection
and transmission of PMDL(DS3) messages including Idle Signal,
Path, and Test Signal Identification messages
- Transmission
of loopback requests at DS3, DS2 and DS1/E1 stages.
- Recognition
and implementation of loopback requests
- Ability,
under application control, to put loopback up/down at DS3,
DS2 and DS1 or E3, E2 and E1 stages.
DS3/E3 Performance Manager Module (PMMM)
- Performance
monitoring done per T1.231/G.747 for DS3 and G.826 for E3.
- User settable
Threshold Crossing Alerts (TCA).
- Maintenance
of 15 minute and 24 hour performance buckets
- Processing
of time of day changes on performance buckets
- Notification
upon closing of performance buckets
- Collection
and creation of the far-end performance data
Top
SONET
Configuration/Alarm Manager Module (SONMM)
SONET Performance Monitoring Manager Module (SONPMM)
- Collect
performance data as specified in ANSI T1.231
- Collect
near end and far end performance statistics
- Data collected
in 24-hour intervals with 15-minute buckets and summary information
- The SONPMM
supports collections of data locked to the time of day
- The application
can retrieve performance information upon request to the SONPMM
- Threshold-crossing
alerts as defined in ANSI T1.231; When enabled, the threshold
crossing alerts will inform the application when a 24-hour
or a 15-minute threshold has been exceeded. The application
can then take appropriate action.
SONET
Automatic Protection Switching Module (SONET APS)
- Full implementation
of linear APS state machine·
- Designed
to accommodate multiprocessor arrangements
- Works across
various hardware architectures
- Built-in
Wait-To-Restore feature· Models fully compliant with
GR-253-CORE
- SONET framer
device independent
SONET Device Driver Module (SONDDM)
- Polymorphic
Device Driver Mapping Methodology permits multiple device drivers
to appear as one virtual device to the SONET Trunk Management
Software
- The SONDDM
allows for multiple chips to provide a complete SONET Interface,
potentially from OC-n to VT1.5, but to operate as one interface
- Performs
mapping between the TMS and your hardware
- Performs
controls and reports low-level events in the framer. For example,
if the SONET Interface is experiencing a Loss Of Frame condition,
the TMS will perform the work in order to determine the Loss
of Frame alarm
Top
- NComm
provides functions for implementing protection switching. The
criteria for triggering a protection switch are left to the
designer.
- The
Trunk Synchronization function captures the current trunk conditions
including all configuration parameters as well as alarm conditions
and timers, and performance report databases. This entire set
of information can then be moved to another trunk as required.
Top
Through
the Altera AMP program, NComm offers the ToneGen and GainGen
Megafunctions.
Top
Yes, NComm also sells the same hardware it uses for software development
and test. This includes our Salem2, five slot, 860 development
platform, and Telecom Interface Modules for all of the framer
devices we support. Our hardware can be used to verify framer
and software functionality, as a target for early software
development and as a reference platform to trouble shoot customer
software issues.
Top
NComm's
roots are in software and hardware telecom consulting engineering.
We are in our fifth year of operation. NComm's experience ranges
from DS0, though T1/E1 and T3 to Primary Rate ISDN. We have
completed projects for the Central Office and Customer including
central office switches, edge devices and PBXs.
From
it's roots in consulting, TMS was conceived and is now the
central focus of our business.
Top
Yes.
We have on-going software contracts and are very active in
the hardware area. In 1999, NComm produced 26 hardware designs.
That number will increase in 2000.
While
we will entertain any need, we try to reserve our consulting
resources for those TMS customers that need additional help
to get their products to market more quickly. We can also provide
an extra pair of eyes to insure a thorough design review.
Top |
