Frequently Asked Questions
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?
What support is included in the license?
What capabilities are offered in your Ethernet OAM modules?
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/SDH TMS modules?
What support does NComm have for T1/E1 and T3/E3 protection switching?
Does NComm have any hardware offerings?
Does NComm have any other software offerings?
What is NComm's Trunk Management Software?
NComm's Trunk Management Software, or TMS, is a completely functional suite of OAM source code covering T1/E1, T3/E3, SONET/SDH, Automatic Protection Switching, Ethernet OAM, Sync Status Message Management as well as traditional telephony signaling. These modules provide configuration, alarm, maintenance/performance monitoring, loopback activation, Robbed-Bit Signaling (T1), Channel-Associated Signaling (E1) and PRI D-Channel signaling. The TMS OAM software sits between the developer's unique applications/capabilities 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.
In addition to the technologies above, LIU packages are also available for T1/E1 and T3/E3 LIUs. Many drivers are available and driver support for the designer's choice is included in each package.
What advantage do I have with NComm TMS rather than developing this software in-house?
With NComm's TMS software, you collapse your WAN or Ethernet 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, E3 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 expense 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.
Additionally, with an NComm solution, you are using software that has been thoroughly tested by NComm and field tested and deployed by the best equipment companies in the world.
Top
Does the TMS employ an Application Programmers Interface (API)?
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 or stack driver. Usually, the developer will only need to work with the application API layer.
Top
Are multiple span devices supported?
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
What framer devices are supported?
Many devices are already supported including most Maxim, Infineon, PMC and LSI framers. 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). There will be no extra charge if a part of a full license.
Top
Is the framer device driver extra?
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
How portable is my application if I want to change platforms?
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
What Operating Systems are supported?
The TMS package comes already ported to Linux (2.4/2.6), 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
What is the typical porting time?
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
What processor is the software written for?
The TMS software is standard ANSI C code, and is therefore processor independent. NComm tests all software on a Motorola 860/8260 platforms with the customer's specific framer device prior to release.
Top
What kind of system resources does the TMS consume?
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
Does the license include source code?
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
What is the source code written in?
The source code is written in standard ANSI C. No assembly code is used.
Top
Does NComm offer trial code?
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
What support is included in the license?
60 days of implementation support to answer questions about TMS is included. In addition, a day of training is provided at NComm's offices.
Is extended support offered?
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
What standards are implemented in your Ethernet OAM TMS modules?
NComm's Ethernet OAM modules currently cover IEEE 802.1ag, ITU Y.1731 and IEEE 802.3ah. Additional standards are in development.
What capabilities are in your T1/E1 TMS modules?
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.
What robbed bit signaling models are supported?
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.
What capabilities are in your T3 and E3 TMS modules?
T3 Configuration/Alarm Manager Module (T3MM)
- 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.
T3/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
What capabilities are in your SONET/SDH TMS modules?
SONET/SDH Configuration/Alarm Manager Module (OCNMM)
- Defining Line Interface Rate (OC-1 through OC-192)
- Defining the structure of the interface
- Line
- Path
- Section
- Virtual Tributaries
- Alarm Declaration and Alarm Clear timers
- Default timer values are per ANSI T1.231
- Line/Section/Path for OC-Ns, STSs, and VTs and which Alarms will be tracked
- Detection and transmission of standard alarms (LOS, RAI, AIS, LOF, etc.)
- Timers for declaration and clearing of alarms are configurable via API calls.
- Alarm transmission - For example, the application can transmit an AIS alarm until a software download has completed.
- Configurable alarms at the Line, Section, and/or Path levels for OC-Ns, STSs, and VTs as required by the application.
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
What support does NComm have for T1, E1, T3 and E3 protection switching?
- 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.
Does NComm have any hardware offerings?
Yes, NComm also sells the same hardware it uses for software development and test. This includes our 860 and 8260 development platforms 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.
Does NComm have any other software offerings?
Through the Altera AMP program, NComm offers the ToneGen and GainGen Megafunctions.
Who is NComm?
NComm's roots are in software and hardware telecom consulting engineering. We have been in business over thirteen years. NComm's experience ranges from DS0, though T1/E1 and T3 to Primary Rate ISDN to Ethernet OAM. We have completed projects for the Central Office and Customer Premise including central office switches, edge devices and PBXs.
Do you provide engineering consulting services?
Yes. We have on-going software contracts and are very active in the hardware area. NComm has produced hundreds of hardware designs over the years.
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