From: stoltz@denwa.Eng.Sun.COM (Ben Stoltz)
Newsgroups: comp.dcom.isdn
Subject: Re: isdn test equipment
Date: 16 Oct 1992 07:09:52 GMT
Organization: Sun Microsystems Inc., Mountain View, CA
NNTP-Posting-Host: denwa
Keywords: isdn, pc, test equipment, BRI

There are many fine ISDN protocol analyzers and simulators on the market,
but if you want something for "free", if your organization is already
going to buy some SPARCstation 10's, and if you are willing to write
your own NT side protocol stack/analyzer/simulator, then use the SS10.

Most of the emphasis on the SS10's ISDN/Audio features at the trade
shows so far has been on the IP/ISDN product or the high quality
audio.  But the ISDN device driver interface is also going to be of
interest to those who want to roll their own layer 2 or 3 ISDN
simulators or analyzers.

The SPARCstation 10 provides two ISDN BRI interfaces. One of them is a
TE, and one of them is an NT. If there is no software using the NT
interface, then the BRI NT connector is electrically identical to the
TE connector.

In Solaris 2.1 the device driver interface provides a packet level
interface to the D and B channels.  In the privacy of your lab, or in
the USA where certification is recommended but not required to
connect to the public network, you may produce and consume packets to
your heart's content.

However, in the USA, it is best to use a proper protocol stack. We have
noticed that the AT&T 5ESS is especially particular about D-channel
protocols. It will disable the BRI line for longer intervals each time
a protocol error is made. I don't know what the formula is, but it is
some sort of leaky bucket algorithm. Eventually one has to wait a day
or so before the switch will listen to the TE again.

If this development is for anything other than personal hobby or
classroom use, then it can be very expensive to do a proper job.
Sometimes, the RBOC has a lab that has free or reasonable cost time
available to developers, but this isn't the rigorous testing needed to
tell if your product covers all of the requirements.  For the North
American market, you will have to test at Bellcore and you will
probably find an expensive piece or two of ISDN test equipment well
worth the cost.

And... as always, these statements are my own. You could have heard, or will
hear all of this from marketing and sales people at TN92 or InterOp this year.
So, if none if this is true, your shouldn't be at all suprised :^)

Ben Stoltz

rl5499@eehp3 (Robert M Laskey III) writes:
>I am designing ISDN TE on a PC platform. The terminal will communicate
>according to the basic rate interface layer 1 protocol specified in CCITT Rec.
>I.430. The local Bell operating company does not provide ISDN service to this
>area code. And even if they did, the line would not provide the versatility
>I desire for test/experimentation.

>Does anyone have information about simple S/T reference point emulators? I am
>not entirely convinced such an animal exists, but assume it does. To clarify,
>I want to emulate communication across the S/T ref. point between TE and the  
>NT with enough versatility to alter protocol and/or data transfer modes. It 
>must behave like NT (e.g. generate signal echo to the TE) but have the 
>capability to generate generic signals and data.    

>Of course, this all has to be free (-:
>Thanks for your help.   

>| Bob Laskey
>| University of Illinois, Urbana-Champaign   rml31294@uxa.cso.uiuc.edu
>| Advanced Digital Systems Laboratory
>	/*BUSH in '92*/

cy92(boolean_t bush) { exit(!bush); }