TELECOM Digest     Sat, 14 Jan 95 08:10:00 CST    Volume 15 : Issue 31

Inside This Issue:                          Editor: Patrick A. Townson

    CFP: Feature Interactions in Communications Systems (Nancy 
Griffeth)
    Satellite / DECNet Problems (Edward B. Toupin)
    Acronym for "Information Superhighway" (Humor Listserv via Bill 
Edwards)
    Modem-Voice Incoming Call Switching (Jan Mandel)
    Legal Problem Due to Modified Radio (David A. Webb)
    Old Rotary Service Question (Bill Parrish)
    Call Overflow Question (Mark Kelly)
    360 Degrees of Jumping the Gun (Paul Robinson)
    FAQs on Campus Connectivity (routers@halcyon.com)
    Would You Believe More Rain on the Way? (TELECOM Digest Editor)

TELECOM Digest is an electronic journal devoted mostly but not
exclusively to telecommunications topics. It is circulated anywhere
there is email, in addition to various telecom forums on a variety of
public service systems and networks including Compuserve and America
On Line. It is also gatewayed to Usenet where it appears as the 
moderated
newsgroup 'comp.dcom.telecom'. 

Subscriptions are available to qualified organizations and individual
readers. Write and tell us how you qualify:

                 * telecom-request@eecs.nwu.edu *

The Digest is edited, published and compilation-copyrighted by Patrick
Townson of Skokie, Illinois USA. You can reach us by postal mail, fax 
or phone at:
                    9457-D Niles Center Road
                     Skokie, IL USA   60076
                       Phone: 708-329-0571
                        Fax: 708-329-0572
  ** Article submission address only: telecom@eecs.nwu.edu **

Our archives are located at lcs.mit.edu and are available by using
anonymous ftp. The archives can also be accessed using our email
information service. For a copy of a helpful file explaining how to
use the information service, just ask.

**********************************************************************
***
*   TELECOM Digest is partially funded by a grant from the              
*
* International Telecommunication Union (ITU) in Geneva, Switzerland    
* 
* under the aegis of its Telecom Information Exchange Services (TIES)   
* 
* project.  Views expressed herein should not be construed as 
represent-*
* ing views of the ITU.                                                 
*
**********************************************************************
***

Additionally, the Digest is funded by gifts from generous readers such
as yourself who provide funding in amounts deemed appropriate. Your 
help 
is important and appreciated. A suggested donation of twenty dollars 
per
year per reader is considered appropriate. See our address above.

All opinions expressed herein are deemed to be those of the author. 
Any
organizations listed are for identification purposes only and messages
should not be considered any official expression by the organization.
----------------------------------------------------------------------

From: nancyg@thumper.bellcore.com (Nancy Griffeth)
Subject: CFP Feature Interactions in Communications Systems
Organization: Morristown Research and Engineering
Date: Fri, 13 Jan 1995 19:55:00 GMT


                   Call for Participation
     Third International Workshop on Feature Interactions
           in Telecommunications Software Systems
                        Kyoto, Japan
                    October 11-13, 1995


Description:

     This workshop is the third in a series, whose mission is to
encourage researchers from a variety of computer science specialties
(software engineering, enterprise modeling, protocol engineering,
distributed artificial intelligence, formal techniques, software
testing, and distributed systems, among others) to apply their
techniques to the feature interaction problem that arises in building
telecommunications software systems (see the back page for a
description of the problem).  We welcome papers on avoiding,
detecting, and/or resolving feature interactions using either
analytical or structural approaches.  Submissions are encouraged in
(but are not limited to) the following topic areas:

   -    Classification of feature interactions.

   -    Modeling,  reasoning,  and  testing  techniques  for
        detecting feature interactions.

   -    Software platforms and architecture designs  to  aid
        in   avoiding,   detecting,  and  resolving  feature
        interactions.

   -    Tools  and  methodologies  for  promoting   software
        compatibility and extensibility.

   -    Mechanisms   for   managing   feature   interactions
        throughout the service life-cyle.

   -    Management of feature interactions in PCS, ISDN, and
        Broadband services, as well as IN services.

   -    Management of feature interactions in various of the
        operations   support   functions   such  as  Service
        Negotiation,   Service   Management,   and   Service
        Assurance.

   -    Feature Interactions and their potential  impact  on
        system Security and Safety.

   -    Environments  and  automated   tools   for   related
        problems in other software systems.

   -    Management of Feature Interactions in various  other
        enterprises, such as banking, medicine, etc.


Format:

     We hope to promote a dialogue among researchers in various
related areas, as well as the designers and builders of
telecommunications software. To this end, the workshop will have
sessions for paper presentations, including relatively long discussion
periods.  Panel discussions and tool demonstrations are also planned.
The first day of the workshop, October 11, is devoted to tutorials and
discussions on areas related to feature interactions.


Attendance:

     Workshop attendance will be limited to 100 people.  Attendance
will be by invitation only. Prospective attendees are asked to submit
either a paper (maximum 5000 words) or a single page description of
their interests and how they relate to the workshop.  Proposals for
tutorials and discussions are also requested (maximum 3000 words).
About 16-20 of the attendees will be asked to present talks; a small
number of tutorials and/or discussions will also be selected.  We will
strive for an equal mix of theoretical results and practical
experiences. Papers will be published in a conference proceedings.


Submissions:

     Please send five copies of your full original paper or interest
description to:

     Kong Eng Cheng
     Department of Computer Science
     Royal Melbourne Institute of Technology
     GPO Box 2476V
     Melbourne, Victoria
     AUSTRALIA 3001

     E-mail: kec@cs.rmit.edu.au
     Tel: +61 3 660 3266
     FAX: +61 3 662 1617


Important dates are:

     February 28, 1995: Submission of contributions.
     May 15, 1995: Notification of acceptance.
     June 26, 1995: Submission of camera-ready versions.


Workshop Co-chairpersons

     Tadashi Ohta (ATR, Japan)
     Nancy Griffeth (Bellcore, USA)

Program Committee

     Co-Chairpersons:
     Kong Eng Cheng  (Royal Melbourne Institute of
                      Technology, Australia)
     E. Jane Cameron (Bellcore, USA)

Jan Bergstra         (CWI and University of Amsterdam,
                      The Netherlands)
Ralph Blumenthal     (Bellcore, USA)
Rolv Braek           (SINTEF DELAB, Norway)
Bernie Cohen         (City University of London, UK)
Robert France        (Florida Atlantic University, USA)
Haruo Hasegawa       (OKI, Japan)
Dieter Hogrefe       (University of Bern, Switzerland)
Richard Kemmerer     (UCSB, USA)
Victor Lesser        (University of Massachusetts, USA)
Yow-Jian Lin         (Bellcore, USA)
Luigi Logrippo       (University of Ottawa, Canada)
Jan van der Meer     (Ericsson, The Netherlands)
Robert Milne         (BNR, UK)
Leo Motus            (Tallinn Technical University, Estonia)
Jacques Muller       (CNET, France)
Jan-Olof Nordenstam  (ELLEMTEL, Sweden)
Yoshihiro Niitsu     (NTT, Japan)
Ben Potter           (University of Hertfordshire, UK)
Henrikas Pranevicius (Kaunas University of Technology,
                      Lithuania)
Martin Sadler        (HP, UK)
Jean-Bernard Stefani (CNET, France)
Greg Utas            (BNR, USA)
Jyri Vain            (Institute of Cybernetics, Estonia)
Hugo Velthuijsen     (PTT Research, The Netherlands)
Yasushi Wakahara     (KDD R&D Laboratories, Japan)
Ron Wojcik           (BellSouth, USA)
Pamela Zave          (AT&T Bell Laboratories, USA)


Workshop Statement:

     The feature interaction problem is a major obstacle to the rapid
deployment of new telephone services. Some feature communications
system. Telecommunications software is huge, real-time, and
distributed; adding new features to a telecommunication system, like
adding new functionalities to any large software system, can be very
difficult.  Each new feature may interact with many existing features,
causing customer annoyance or total system breakdown.  Traditionally,
interactions were detected and resolved on a feature by feature basis
by experts who are knowledgeable on all existing features.  As the
number of features grows to satisfy diverse needs of customers,
managing feature interactions in a single administrative domain is
approaching incomprehensible complexity.  In a future marketplace
where features deployed in the network may be developed by different
operating companies and their associated vendors, the traditional
approach is no longer feasible.  How to detect, resolve, or even
prevent the occurrence of feature interactions in an open network is
now an important research issue.

The feature interaction problem is not unique to telecommunications
software; similar problems are encountered in any long-lived software
system that requires frequent changes and additions to its
functionality.  Techniques in many related areas appear to be
applicable to the management of feature interactions.  Software
methodologies for extensibility and compatibility, for example, could
be useful for providing a structured design that can prevent many
feature interactions from occurring.  Features are typically design to
suit the purposes of a user or business, hence Enterprise modeling
will play a role in the identification of certain classes of
interaction, in particular the solution of an interaction in one
enterprise may not be desired by another.  Formal specification,
verification, and testing techniques, being widely used in protocol
engineering and software engineering, contribute to the detection of
interactions.  Several causes of the problem, such as aliasing,
timing, and the distribution of software components, are similar to
issues in distributed systems.  Cooperative problem solving, a
promising approach for resolving interactions at run time, resembles
distributed planning and resolution of conflicting subgoals among
multiple agents in the area of distributed artificial intelligence.
This workshop aims to provide an opportunity for participants to share
ideas and experiences in their respective fields, and to apply their
expertise to the feature interaction problem.


Workshop Announcement:

     3nd International Workshop on Feature Interactions in
Telecommunications Software Systems, October 11-13, Kyoto, Japan,
Sponsors: IEEE Communications Society. In cooperation with ACM SIGCOMM
and ATR, Japan. Contact Tadashi Ohta, ATR, 2-2, Hikari-dai, Seika-cho,
Soraku-gun, Kyoto, 619-02, Japan, Tel: +81 7749 5 1230, Fax: +81 7749
5 1208, e-mail: ohta@atr-sw.atr.co.jp.

------------------------------

From: etoupin@toupin.com (Edward B. Toupin)
Subject: Satellite / DECNet Problems
Date: 13 Jan 1995 15:53:26 GMT
Organization: Edward B. Toupin
Reply-To: sn=morrison%g=tom%i=p%dda=tel=3536%texaco@mcimail.com,


The message is sent for an associate.

TOM MORRISON writes:

We currently have an application in which DEC VAXStations communicate
through DECRouter 2000s.  The local area network uses DECNet and the
routers that connect disparate local area networks communicate via 56k
leased data circuits.  The required throughput on these circuits does
not exceed 20k.

It is our desire to provide a diverse route for data using an X.25
based double hop satellite system.  This circuit configuration has
approximately 1.5 seconds of processing and propogation delay.

In testing the proposed configuration, 56kb modems were connected back
to back to conduct 1 megabyte file transfers using X.25.  In this
configuraton, circuit throughput averaged 45kbps.  The modems were
then replaced with a satellite circuit which caused the throughput to
drop off to 1100 bps!  Incidently the satellite system provides local
acknowledgements at the X.25 level and no flow control messages were
seen.

In evaluating the satellite throughput, we have been told that DECNet
has a required acknowledgement for either one of four packets
generated at the NSP level.  This acknowledgement is hard coded into
DECNet and can't be changed.  These required acknowledgements, coupled
with the long propogation time of the satellite system combine to
limit throughput.

Please provide any insight you may have to the following questions:

1. Are NSP acknowledgements required after each or 
 every fourth packet?

2. We thought that adjusting the buffer sizes in the 
 routers would change packet sizes, however, in 
 monitoring data communication with Trace we
 didn't see any change in packet size.  Can packet 
 sizes be changed (increased)?

3. Has anyone had similar experiences with similar results?

4. Any ideas about how we may increase throughput in 
 the double hop satellite system?


Regards,

Tom Morrison

------------------------------

Date: Fri, 13 Jan 95 12:53:13 EST
From: Bill <BEDWARDS@uga.cc.uga.edu>
Subject: Acronym for "Information Superhighway"


For the benefit of the readers...

Bill Edwards, HUMOR listowner, BEDWARDS@UGA.BITNET (uga.cc.uga.edu)
=====================================================================
To leave HUMOR send LISTSERV@UGA.CC.UGA.EDU the command SIGNOFF HUMOR
To subscribe send LISTSERV@UGA.CC.UGA.EDU the command SUB HUMOR Call-
name FamilyName. A command goes in the 1st line of the message field.

            -------------Original message--------------
Date:         Thu, 12 Jan 1995 19:03:12 -0500
Sender:       UGA Humor List <HUMOR@UGA.BITNET>
From:         "Greg V." <NYGreg@AOL.COM>
Subject:      Acronym

INFORMATION SUPERHIGHWAY:

Interactive Network For Organizing, Retrieving, Manipulating, 
Accessing, 
and Transferring Information On National Systems, Unleashing 
Practically 
Every Rebellious Human Intelligence, Gratifying Hackers, Wiseasses,
And Yahoos.

Thanks to Kevin Kwaku, who obvoiusly has way too much time on his 
hands.

   - Greg V.
     NYGreg@AOL.COM
     "Roadkill on the Information Superhighway"

                    ----------------

[TELECOM Digest Editor's Note: Gee, it sounds just like the CB Radio
era back in the late 1970's when CB was at its height of popularity.
The crazy people ruined CB ... I guess now they will make things so
miserable on the Internet large numbers of people will drop out.   
PAT]

------------------------------

From: jmandel@carbon.cudenver.edu (Jan Mandel)
Subject: Modem-Voice Incoming Call Switching
Date: 13 Jan 1995 11:31:39 -0700
Organization: University of Colorado at Denver


A while ago I have posted a question how to switch incoming calls to
an answering machine or a modem. Many have pointed out that incoming
modem call is just silence and it is the answering modem that makes
the shreeking noise. Thank you all.

Consequently to decide if the incoming call is modem or not one would
have to subject all callers to the unpleasant shreek.

Here is another possible solution: let an answering machine take all
calls.  If there is silence on the line after the beep (all answering
machines can detect this condition), let it time out and switch to the
answering modem. Since I need this for my office where after office
hours I would dial in or others may call in to leave a message, that


would work for my needs. I'll set the timeout for my calling modem
large so that it waits longer for the carrier. I was also looking for
a modem setup parameter like "answer only after 60 seconds" for the
asnwering side but could find none.

Anyone knows what hardware I may need for this? I need to buy an
answering machine for the office anyway so I may just as well buy the
right one. I already have a pair of Hayes Accura 288 V.FC modems a
year old.

No, I canot use alternate ring because this is a PBX line. This whole
exercise is because of our phone bozos who will not let me have
another PBX (=cheap) line in the office once they heard we have
modems, for fear I actually might use it. A separate telco line would
be too expensive.

TIA for any suggestions.


Jan Mandel, Center for Computational Math, 
University of Colorado at Denver   jmandel@colorado.edu

------------------------------

From: mudaw@uxa.ecn.bgu.edu (David A. Webb)
Subject: Legal Problem Due to Modified Radio
Date: 13 Jan 1995 17:55:40 -0600
Organization: Educational Computing Network


Dear Moderator,

I was rather impressed with your knowledge of FCC regulations.
 
I read that you are an attorney, and I know time is money, but I
thought you would be interested in my situation.
 
University police searched my dorm room in November, 1992 after I
consented to the search.   (Mistake #1)
 
An officer found my 2 meter amateur transceiver, turned it on, and
discovered it could transmit on frequencies licensed to the local
county police.  I was not in my room during the time of the search,
so I had no control over its operation.  
 
The radio was confiscated, and I had to defend myself in front of
the school board.  The school did not find me in violation of any
rules because I had a statement from a county officer who is also
a Ham.  The officer wrote he knew my radio was legal for me to
possess.  
 
I was never accused of using the radio.  I was never charged in a
court of law concerning the radio.
 
I petitioned the court for the return of personal property.  This was
December 20, 1994.
 
I didn't take any evidence to support my side (Mistake #2).
 
The States attorney had three witnesses.  
 
Witness #1 was the university officer who stated under oath that he
used the radio to transmit on county frequencies to verify the
modifications.  He also stated in his professional capacity that my
radio is illegally modified, and therefor illegal to possess.  He
further stated that he called the FCC and was told my radio is illegal
to possess.
 
Witness #2 was the county sheriff.  He indicated in his professional
capacity that my radio was illegal to own.  He also voiced
understandable concern for my capability to interfere with his
frequencies.
 
Witness #3 was a person who services amateur equipment.  He stated
that my radio is type accepted, and therefor it is illegal to modify.
Illegal modification therefor makes my radio illegal to possess.
 
The University officer must have called the field office in Chicago,
because when I called there, I was also told my radio is illegal to
possess.  I called the Washington office, and the Director of the
Private Radio Division is sending me a statement which will say that
my radio is legal for anyone to possess, and its use is regulated by
the FCC.  (unless local laws prohibit a radio which will transmit on
police channels)
 
Witness #2 was simply giving an opinion.
 
Witness #3 was wrong about the type acceptance.  Amateur equipment
transmitters are not type accepted.  Its internal receiver it accepted
to receive everything it was modified to receive.
 
I tried to submit the county officer/ham's statement, and the states
attorney objected because the officer was not present for cross
examination.
 
Am I going to run into the same trouble when I try to submit the
statement from the Private Radio Division of the FCC?  If so, how can
I get around this obstacle?
 
I reported the discrepancy of the field office to the FCC's General
Councils Office, and they will be investigating the person who gave me
the faulty information.
 
Although the university police violated FCC rules, it occurred over a
year ago, and therefor time limits on me reporting them has expired.
 
Neither the States Attorney, nor any of his witnesses, presented the
judge with any law I *supposedly* violated.
 
The judge ruled to NOT allow me to have my radio back UNLESS I paid
to have it unmodified.  
 
I filed a motion for the Judge to reconsider his ruling, which is
scheduled for February 9.  
 
The reason I have opted to do this on my own is that the radio isn't
worth more than a few hundred bucks.  I am pursuing this on the
principal.  My radio is legal for me to own, and I am tired of the
harassment from university police.
 
Please send your comments to me at mudaw@ecom.ecn.bgu.edu.


[TELECOM Digest Editor's Note: First, and most important, I am not an
attorney, and you are not my client. I will suggest that depending on
how strongly you feel about the principles involved here and getting
your equipment returned, you *should* consult an attorney who 
specializes
in communications law, preferably in your community if possible, 
although
quite a few (most?) of those people are in practice in Washington, DC
and environs. We do have attornies whose practice is specialized in 
the
area of federal communications law on the Digest mailing list, and
perhaps one or more of them will respond to you directly at least once
on a pro-bono basis offering some suggestions or help. My feeling is
the cost involved for *good* legal representation in this area will
be far in excess of the value of the equipment involved. This will 
have
to be your decision in connection with any discussions you have with
an attorney who is competent to assist you. I cannot do so. Good luck
with this. Perhaps other Digest readers will have suggestions also.  
PAT]

------------------------------

From: Bill Parrish <bparrish@bp700.rose.hp.com>
Subject: Old Rotary Service Question
Date: Fri, 13 Jan 95 7:58:32 PST


Pat's reply to the thread about scanners and cordless phones dealing
with party lines reminded me of something I had always wondered
about.

In the early 70s, I went to UCSB, and we were serviced by GTE in the
dorms.  Occasionaly folks would decide to "share" a phone connection
by making their own patches into terminal cabinets ... resulting in an
illegal but effective party line arrangement.  I recall that if the
phone had the wrong type of filter in it that you would sometimes get
the "pinging" sound rather than a vigorous "ring" when an incoming
call came in.

But there was a second funny thing about these "extensions" that was
rather odd ... you sometimes could not make long distance calls  on
them ... and that always seemed odd to me.  If I recall right, there
was some sort of a movable pin on the back of the dial that could
be put into one of several (three?) positions, and if you moved
the pin, it would enable the long-distance capability.  Could someone
explain how that worked?  (I could be remembering wrong ... it's been
a long time, but I always wondered how that worked).



Bill Parrish (916) 785-4986
M6KV      Hewlett Packard 
Systems Technology Division
8000 Foothills Blvd.
Roseville, CA 95747-5596 
HPDesk: Bill_parrish@hp5200.desk.hp.com
Unix to Unix: bparrish@hprpcd.rose.hp.com
Fax:  (916) (or TELNET) - 785-3096  

------------------------------

From: mkelly@gabriel.resudox.net (Mark Kelly)
Subject: Call Overflow Question
Date: 13 Jan 1995 22:38:58 GMT
Organization: Resudox Online Services


I have question for the telephony wizards out there.

A single number DN #1 has been assigned to a trunk group (say a T1, 24
channels). When all 24 channels are busy, its desirable to route all
incoming calls to the DN #1 to another number (DN #2).

Can anyone think of a way to do this that doesn't involve adding a
extra trunk group at the switch and pointing it to the second number.

Any suggestions or hints would be welcome.


Mark Kelly                        
Advanced Multi-Point Conferencing 
320 March Road, Suite 102         
Kanata, Ontario  K2L 1Z8                           
1-800-900-4249 (Reservations)     
1-613-592-5752                    

------------------------------

Date: Fri, 13 Jan 1995 19:33:42 EST 
From: Paul Robinson <paul@tdr.com>
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
Subject: 360 Degrees of Jumping the Gun


I decided to check Pat Towson's comments about the 630 area code in 
Chicago.  I first tried 1-700-555-1212 and it told me I have AT&T.

I dialed 1-630-555-1212 and when asked what city, I asked the operator
if it was the Chicago operator, and she said yes.  I realized I really
didn't have a reason to call anyone there.

So, next I decided to see if the new area codes are in place here, and 
dialed 1-360-555-1 

Oops, the phone times out on me!

Now, for the fun part.  I dial 611 and explain that I *can* call 1-630 
but *can't* call 1-360 and the agent says "It must be in your phone."

Yeah, right.  I explained that I have dialed the number by going 
through 
1-800-CALL-ATT and using a calling card.  

I explained that the same thing happens from other phones, on 
different 
lines.  

She put me on hold and when she came back she said that there is a 
routing problem, and she'll write up a trouble ticket.   We'll see 
what 
happens.

It must have been difficult (knowing my trouble with Bell Atlantic)
because I got a return call a few minutes ago, about an hour after I
placed the call to 611.

According to the person calling me, the "official" date that area code 
360 goes into effect isn't until tomorrow, which is why Bell Atlantic 
is 
not accepting calls placed to that area code yet.

So, if the statment is correct, those places that are accepting calls
to the 360 area code are actually "jumping the gun".

------------------------------

From: routers@halcyon.com
Subject: FAQs on Campus Connectivity
Date: 13 Jan 1995 12:14:06 GMT
Organization: Northwest Nexus Inc.


        NEW ANSWERS FOR FAQs ON CAMPUS NETWORKS AND CONNECTIVITY

This posting may be freely distributed to Internet and commercial
online sites.

Date:     January 12, 1994

Keywords: UTP distance standards, campus networks connectivity,
          ethernet, wireless, LAN, microwave, repeaters, video 


1.  QUESTION:   What is the maximum bandwidth that 4-wire copper
                UTP can handle in campus environments?
    ANSWER:     ---E-1 up to 2.5 miles (4 km)

2.  QUESTION:   What is the longest distance that 4-wire copper
                UTP can transmit at T-1 band width?
    ANSWER:     ---5 miles (8 km), up to 7 miles (11.2 km) with 
                   a repeater 
                
3.  QUESTION:   Can you transmit data, voice, and video across
                4-wire UTP at the same time without cross-talk?
    ANSWER:     ---Yes
    
4.  QUESTION:   What is the maximum distance that ethernet at
                10 Mbps can be extended?
    ANSWER:     ---1500 ft (495 m), up to 3000 ft (990 m) with
                   repeater
                   
5.  QUESTION:   Is there a wireless solution that would allow a
                campus to connect all buildings together, and
                allow any PC or laptop computer on campus to
                communicate, even if they move about the campus?
    ANSWER:     ---Yes.  One solution allows building -to-
                   building connections up to 6 miles (9.6 km), 
                   and allows any PC or laptop to be on
                   line.  It operates at 2 Mbps, has SNMP, and
                   requires no FCC licence.
                   
6.  QUESTION:   Are there any wireless solutions at 10 Mbps for
                LAN-to-LAN connections? 
    ANSWER:     ---Yes.  A microwave solution allows LANs to
                   connect up to 5 miles (8 km).  This same
                   system has options that will allow voice,
                   data, and video at the same time, in either
                   4 -T1 slots, or 8 -T1 slots.  The 8 -T1
                   version can handle 192 voice-grade circuits.


For further information and product data sheets, please contact
Router Solutions (routers@halcyon.com), or check our FTP site:
        ftp.halcyon.com   /pub/local/routers

------------------------------

From: TELECOM Digest Editor <telecom@eecs.nwu.edu>
Subject: Would You Believe More Rain on the Way?
Date: Sat, 14 Jan 1995 08:00:00 CST


Listening to WNIB on the radio this Saturday morning as I work on
this issue ... the eight o'clock news says 'up to six more inches
of rain due in California throughout the weekend ... more evacuations
probably will be required ...'

Well, good luck and my best regards, folks. It seems like the people
in California spend all summer burning the place down, then spend
all winter enduring mud slides and flooding. We are getting a lot
of rain here today also, but the only effect has been to melt all
the snow which had accumulated and leave some *huge* puddles of water
to navigate at curbs where the street sewers are plugged, etc.

Have the floods in California affected telephone service to any 
extent?


PAT

------------------------------

End of TELECOM Digest V15 #31
*****************************

                                  

@FROM   :telecom@delta.eecs.nwu.edu                                   
Message-ID: <9501141411.AA14245@delta.eecs.nwu.edu>
From telecom-request@delta.eecs.nwu.edu  Sat Jan 14 10:25:00 1995
Received: from delta.eecs.nwu.edu (delta.eecs.nwu.edu [129.105.5.103]) 
by
coyote.channel1.com (8.6.9/8.6.4) with SMTP id KAA13091; Sat, 14 Jan 
1995
10:25:00 -0500
Received: by delta.eecs.nwu.edu (4.1/SMI-4.0-proxy)
 id AA14253; Sat, 14 Jan 95 08:11:21 CST
Received: by delta.eecs.nwu.edu (4.1/SMI-4.0-proxy)
 id AA14245; Sat, 14 Jan 95 08:11:17 CST
Date: Sat, 14 Jan 95 08:11:17 CST
From: telecom@delta.eecs.nwu.edu (TELECOM Digest (Patrick Townson))
Message-Id: <9501141411.AA14245@delta.eecs.nwu.edu>
To: telecom@eecs.nwu.edu
Subject: TELECOM Digest V15 #31


TELECOM Digest     Sat, 14 Jan 95 08:10:00 CST    Volume 15 : Issue 31

Inside This Issue:                          Editor: Patrick A. Townson

    CFP: Feature Interactions in Communications Systems (Nancy 
Griffeth)
    Satellite / DECNet Problems (Edward B. Toupin)
    Acronym for "Information Superhighway" (Humor Listserv via Bill 
Edwards)
    Modem-Voice Incoming Call Switching (Jan Mandel)
    Legal Problem Due to Modified Radio (David A. Webb)
    Old Rotary Service Question (Bill Parrish)
    Call Overflow Question (Mark Kelly)
    360 Degrees of Jumping the Gun (Paul Robinson)
    FAQs on Campus Connectivity (routers@halcyon.com)
    Would You Believe More Rain on the Way? (TELECOM Digest Editor)

TELECOM Digest is an electronic journal devoted mostly but not
exclusively to telecommunications topics. It is circulated anywhere
there is email, in addition to various telecom forums on a variety of
public service systems and networks including Compuserve and America
On Line. It is also gatewayed to Usenet where it appears as the 
moderated
newsgroup 'comp.dcom.telecom'. 

Subscriptions are available to qualified organizations and individual
readers. Write and tell us how you qualify:

                 * telecom-request@eecs.nwu.edu *

The Digest is edited, published and compilation-copyrighted by Patrick
Townson of Skokie, Illinois USA. You can reach us by postal mail, fax 
or phone at:
                    9457-D Niles Center Road
                     Skokie, IL USA   60076
                       Phone: 708-329-0571
                        Fax: 708-329-0572
  ** Article submission address only: telecom@eecs.nwu.edu **

Our archives are located at lcs.mit.edu and are available by using
anonymous ftp. The archives can also be accessed using our email
information service. For a copy of a helpful file explaining how to
use the information service, just ask.

**********************************************************************
***
*   TELECOM Digest is partially funded by a grant from the              
*
* International Telecommunication Union (ITU) in Geneva, Switzerland    
* 
* under the aegis of its Telecom Information Exchange Services (TIES)   
* 
* project.  Views expressed herein should not be construed as 
represent-*
* ing views of the ITU.                                                 
*
**********************************************************************
***

Additionally, the Digest is funded by gifts from generous readers such
as yourself who provide funding in amounts deemed appropriate. Your 
help 
is important and appreciated. A suggested donation of twenty dollars 
per
year per reader is considered appropriate. See our address above.

All opinions expressed herein are deemed to be those of the author. 
Any
organizations listed are for identification purposes only and messages
should not be considered any official expression by the organization.
----------------------------------------------------------------------

From: nancyg@thumper.bellcore.com (Nancy Griffeth)
Subject: CFP Feature Interactions in Communications Systems
Organization: Morristown Research and Engineering
Date: Fri, 13 Jan 1995 19:55:00 GMT


                   Call for Participation
     Third International Workshop on Feature Interactions
           in Telecommunications Software Systems
                        Kyoto, Japan
                    October 11-13, 1995


Description:

     This workshop is the third in a series, whose mission is to
encourage researchers from a variety of computer science specialties
(software engineering, enterprise modeling, protocol engineering,
distributed artificial intelligence, formal techniques, software
testing, and distributed systems, among others) to apply their
techniques to the feature interaction problem that arises in building
telecommunications software systems (see the back page for a
description of the problem).  We welcome papers on avoiding,
detecting, and/or resolving feature interactions using either
analytical or structural approaches.  Submissions are encouraged in
(but are not limited to) the following topic areas:

   -    Classification of feature interactions.

   -    Modeling,  reasoning,  and  testing  techniques  for
        detecting feature interactions.

   -    Software platforms and architecture designs  to  aid
        in   avoiding,   detecting,  and  resolving  feature
        interactions.

   -    Tools  and  methodologies  for  promoting   software
        compatibility and extensibility.

   -    Mechanisms   for   managing   feature   interactions
        throughout the service life-cyle.

   -    Management of feature interactions in PCS, ISDN, and
        Broadband services, as well as IN services.

   -    Management of feature interactions in various of the
        operations   support   functions   such  as  Service
        Negotiation,   Service   Management,   and   Service
        Assurance.

   -    Feature Interactions and their potential  impact  on
        system Security and Safety.

   -    Environments  and  automated   tools   for   related
        problems in other software systems.

   -    Management of Feature Interactions in various  other
        enterprises, such as banking, medicine, etc.


Format:

     We hope to promote a dialogue among researchers in various
related areas, as well as the designers and builders of
telecommunications software. To this end, the workshop will have
sessions for paper presentations, including relatively long discussion
periods.  Panel discussions and tool demonstrations are also planned.
The first day of the workshop, October 11, is devoted to tutorials and
discussions on areas related to feature interactions.


Attendance:

     Workshop attendance will be limited to 100 people.  Attendance
will be by invitation only. Prospective attendees are asked to submit
either a paper (maximum 5000 words) or a single page description of
their interests and how they relate to the workshop.  Proposals for
tutorials and discussions are also requested (maximum 3000 words).
About 16-20 of the attendees will be asked to present talks; a small
number of tutorials and/or discussions will also be selected.  We will
strive for an equal mix of theoretical results and practical
experiences. Papers will be published in a conference proceedings.


Submissions:

     Please send five copies of your full original paper or interest
description to:

     Kong Eng Cheng
     Department of Computer Science
     Royal Melbourne Institute of Technology
     GPO Box 2476V
     Melbourne, Victoria
     AUSTRALIA 3001

     E-mail: kec@cs.rmit.edu.au
     Tel: +61 3 660 3266
     FAX: +61 3 662 1617


Important dates are:

     February 28, 1995: Submission of contributions.
     May 15, 1995: Notification of acceptance.
     June 26, 1995: Submission of camera-ready versions.


Workshop Co-chairpersons

     Tadashi Ohta (ATR, Japan)
     Nancy Griffeth (Bellcore, USA)

Program Committee

     Co-Chairpersons:
     Kong Eng Cheng  (Royal Melbourne Institute of
                      Technology, Australia)
     E. Jane Cameron (Bellcore, USA)

Jan Bergstra         (CWI and University of Amsterdam,
                      The Netherlands)
Ralph Blumenthal     (Bellcore, USA)
Rolv Braek           (SINTEF DELAB, Norway)
Bernie Cohen         (City University of London, UK)
Robert France        (Florida Atlantic University, USA)
Haruo Hasegawa       (OKI, Japan)
Dieter Hogrefe       (University of Bern, Switzerland)
Richard Kemmerer     (UCSB, USA)
Victor Lesser        (University of Massachusetts, USA)
Yow-Jian Lin         (Bellcore, USA)
Luigi Logrippo       (University of Ottawa, Canada)
Jan van der Meer     (Ericsson, The Netherlands)
Robert Milne         (BNR, UK)
Leo Motus            (Tallinn Technical University, Estonia)
Jacques Muller       (CNET, France)
Jan-Olof Nordenstam  (ELLEMTEL, Sweden)
Yoshihiro Niitsu     (NTT, Japan)
Ben Potter           (University of Hertfordshire, UK)
Henrikas Pranevicius (Kaunas University of Technology,
                      Lithuania)
Martin Sadler        (HP, UK)
Jean-Bernard Stefani (CNET, France)
Greg Utas            (BNR, USA)
Jyri Vain            (Institute of Cybernetics, Estonia)
Hugo Velthuijsen     (PTT Research, The Netherlands)
Yasushi Wakahara     (KDD R&D Laboratories, Japan)
Ron Wojcik           (BellSouth, USA)
Pamela Zave          (AT&T Bell Laboratories, USA)


Workshop Statement:

     The feature interaction problem is a major obstacle to the rapid
deployment of new telephone services. Some feature communications
system. Telecommunications software is huge, real-time, and
distributed; adding new features to a telecommunication system, like
adding new functionalities to any large software system, can be very
difficult.  Each new feature may interact with many existing features,
causing customer annoyance or total system breakdown.  Traditionally,
interactions were detected and resolved on a feature by feature basis
by experts who are knowledgeable on all existing features.  As the
number of features grows to satisfy diverse needs of customers,
managing feature interactions in a single administrative domain is
approaching incomprehensible complexity.  In a future marketplace
where features deployed in the network may be developed by different
operating companies and their associated vendors, the traditional
approach is no longer feasible.  How to detect, resolve, or even
prevent the occurrence of feature interactions in an open network is
now an important research issue.

The feature interaction problem is not unique to telecommunications
software; similar problems are encountered in any long-lived software
system that requires frequent changes and additions to its
functionality.  Techniques in many related areas appear to be
applicable to the management of feature interactions.  Software
methodologies for extensibility and compatibility, for example, could
be useful for providing a structured design that can prevent many
feature interactions from occurring.  Features are typically design to
suit the purposes of a user or business, hence Enterprise modeling
will play a role in the identification of certain classes of
interaction, in particular the solution of an interaction in one
enterprise may not be desired by another.  Formal specification,
verification, and testing techniques, being widely used in protocol
engineering and software engineering, contribute to the detection of
interactions.  Several causes of the problem, such as aliasing,
timing, and the distribution of software components, are similar to
issues in distributed systems.  Cooperative problem solving, a
promising approach for resolving interactions at run time, resembles
distributed planning and resolution of conflicting subgoals among
multiple agents in the area of distributed artificial intelligence.
This workshop aims to provide an opportunity for participants to share
ideas and experiences in their respective fields, and to apply their
expertise to the feature interaction problem.


Workshop Announcement:

     3nd International Workshop on Feature Interactions in
Telecommunications Software Systems, October 11-13, Kyoto, Japan,
Sponsors: IEEE Communications Society. In cooperation with ACM SIGCOMM
and ATR, Japan. Contact Tadashi Ohta, ATR, 2-2, Hikari-dai, Seika-cho,
Soraku-gun, Kyoto, 619-02, Japan, Tel: +81 7749 5 1230, Fax: +81 7749
5 1208, e-mail: ohta@atr-sw.atr.co.jp.

------------------------------

From: etoupin@toupin.com (Edward B. Toupin)
Subject: Satellite / DECNet Problems
Date: 13 Jan 1995 15:53:26 GMT
Organization: Edward B. Toupin
Reply-To: sn=morrison%g=tom%i=p%dda=tel=3536%texaco@mcimail.com,


The message is sent for an associate.

TOM MORRISON writes:

We currently have an application in which DEC VAXStations communicate
through DECRouter 2000s.  The local area network uses DECNet and the
routers that connect disparate local area networks communicate via 56k
leased data circuits.  The required throughput on these circuits does
not exceed 20k.

It is our desire to provide a diverse route for data using an X.25
based double hop satellite system.  This circuit configuration has
approximately 1.5 seconds of processing and propogation delay.

In testing the proposed configuration, 56kb modems were connected back
to back to conduct 1 megabyte file transfers using X.25.  In this
configuraton, circuit throughput averaged 45kbps.  The modems were
then replaced with a satellite circuit which caused the throughput to
drop off to 1100 bps!  Incidently the satellite system provides local
acknowledgements at the X.25 level and no flow control messages were
seen.

In evaluating the satellite throughput, we have been told that DECNet
has a required acknowledgement for either one of four packets
generated at the NSP level.  This acknowledgement is hard coded into
DECNet and can't be changed.  These required acknowledgements, coupled
with the long propogation time of the satellite system combine to
limit throughput.

Please provide any insight you may have to the following questions:

1. Are NSP acknowledgements required after each or 
 every fourth packet?

2. We thought that adjusting the buffer sizes in the 
 routers would change packet sizes, however, in 
 monitoring data communication with Trace we
 didn't see any change in packet size.  Can packet 
 sizes be changed (increased)?

3. Has anyone had similar experiences with similar results?

4. Any ideas about how we may increase throughput in 
 the double hop satellite system?


Regards,

Tom Morrison

------------------------------

Date: Fri, 13 Jan 95 12:53:13 EST
From: Bill <BEDWARDS@uga.cc.uga.edu>
Subject: Acronym for "Information Superhighway"


For the benefit of the readers...

Bill Edwards, HUMOR listowner, BEDWARDS@UGA.BITNET (uga.cc.uga.edu)
=====================================================================
To leave HUMOR send LISTSERV@UGA.CC.UGA.EDU the command SIGNOFF HUMOR
To subscribe send LISTSERV@UGA.CC.UGA.EDU the command SUB HUMOR Call-
name FamilyName. A command goes in the 1st line of the message field.

            -------------Original message--------------
Date:         Thu, 12 Jan 1995 19:03:12 -0500
Sender:       UGA Humor List <HUMOR@UGA.BITNET>
From:         "Greg V." <NYGreg@AOL.COM>
Subject:      Acronym

INFORMATION SUPERHIGHWAY:

Interactive Network For Organizing, Retrieving, Manipulating, 
Accessing, 
and Transferring Information On National Systems, Unleashing 
Practically 
Every Rebellious Human Intelligence, Gratifying Hackers, Wiseasses,
And Yahoos.

Thanks to Kevin Kwaku, who obvoiusly has way too much time on his 
hands.

   - Greg V.
     NYGreg@AOL.COM
     "Roadkill on the Information Superhighway"

                    ----------------

[TELECOM Digest Editor's Note: Gee, it sounds just like the CB Radio
era back in the late 1970's when CB was at its height of popularity.
The crazy people ruined CB ... I guess now they will make things so
miserable on the Internet large numbers of people will drop out.   
PAT]

------------------------------

From: jmandel@carbon.cudenver.edu (Jan Mandel)
Subject: Modem-Voice Incoming Call Switching
Date: 13 Jan 1995 11:31:39 -0700
Organization: University of Colorado at Denver


A while ago I have posted a question how to switch incoming calls to
an answering machine or a modem. Many have pointed out that incoming
modem call is just silence and it is the answering modem that makes
the shreeking noise. Thank you all.

Consequently to decide if the incoming call is modem or not one would
have to subject all callers to the unpleasant shreek.

Here is another possible solution: let an answering machine take all
calls.  If there is silence on the line after the beep (all answering
machines can detect this condition), let it time out and switch to the
answering modem. Since I need this for my office where after office
hours I would dial in or others may call in to leave a message, that


would work for my needs. I'll set the timeout for my calling modem
large so that it waits longer for the carrier. I was also looking for
a modem setup parameter like "answer only after 60 seconds" for the
asnwering side but could find none.

Anyone knows what hardware I may need for this? I need to buy an
answering machine for the office anyway so I may just as well buy the
right one. I already have a pair of Hayes Accura 288 V.FC modems a
year old.

No, I canot use alternate ring because this is a PBX line. This whole
exercise is because of our phone bozos who will not let me have
another PBX (=cheap) line in the office once they heard we have
modems, for fear I actually might use it. A separate telco line would
be too expensive.

TIA for any suggestions.


Jan Mandel, Center for Computational Math, 
University of Colorado at Denver   jmandel@colorado.edu

------------------------------

From: mudaw@uxa.ecn.bgu.edu (David A. Webb)
Subject: Legal Problem Due to Modified Radio
Date: 13 Jan 1995 17:55:40 -0600
Organization: Educational Computing Network


Dear Moderator,

I was rather impressed with your knowledge of FCC regulations.
 
I read that you are an attorney, and I know time is money, but I
thought you would be interested in my situation.
 
University police searched my dorm room in November, 1992 after I
consented to the search.   (Mistake #1)
 
An officer found my 2 meter amateur transceiver, turned it on, and
discovered it could transmit on frequencies licensed to the local
county police.  I was not in my room during the time of the search,
so I had no control over its operation.  
 
The radio was confiscated, and I had to defend myself in front of
the school board.  The school did not find me in violation of any
rules because I had a statement from a county officer who is also
a Ham.  The officer wrote he knew my radio was legal for me to
possess.  
 
I was never accused of using the radio.  I was never charged in a
court of law concerning the radio.
 
I petitioned the court for the return of personal property.  This was
December 20, 1994.
 
I didn't take any evidence to support my side (Mistake #2).
 
The States attorney had three witnesses.  
 
Witness #1 was the university officer who stated under oath that he
used the radio to transmit on county frequencies to verify the
modifications.  He also stated in his professional capacity that my
radio is illegally modified, and therefor illegal to possess.  He
further stated that he called the FCC and was told my radio is illegal
to possess.
 
Witness #2 was the county sheriff.  He indicated in his professional
capacity that my radio was illegal to own.  He also voiced
understandable concern for my capability to interfere with his
frequencies.
 
Witness #3 was a person who services amateur equipment.  He stated
that my radio is type accepted, and therefor it is illegal to modify.
Illegal modification therefor makes my radio illegal to possess.
 
The University officer must have called the field office in Chicago,
because when I called there, I was also told my radio is illegal to
possess.  I called the Washington office, and the Director of the
Private Radio Division is sending me a statement which will say that
my radio is legal for anyone to possess, and its use is regulated by
the FCC.  (unless local laws prohibit a radio which will transmit on
police channels)
 
Witness #2 was simply giving an opinion.
 
Witness #3 was wrong about the type acceptance.  Amateur equipment
transmitters are not type accepted.  Its internal receiver it accepted
to receive everything it was modified to receive.
 
I tried to submit the county officer/ham's statement, and the states
attorney objected because the officer was not present for cross
examination.
 
Am I going to run into the same trouble when I try to submit the
statement from the Private Radio Division of the FCC?  If so, how can
I get around this obstacle?
 
I reported the discrepancy of the field office to the FCC's General
Councils Office, and they will be investigating the person who gave me
the faulty information.
 
Although the university police violated FCC rules, it occurred over a
year ago, and therefor time limits on me reporting them has expired.
 
Neither the States Attorney, nor any of his witnesses, presented the
judge with any law I *supposedly* violated.
 
The judge ruled to NOT allow me to have my radio back UNLESS I paid
to have it unmodified.  
 
I filed a motion for the Judge to reconsider his ruling, which is
scheduled for February 9.  
 
The reason I have opted to do this on my own is that the radio isn't
worth more than a few hundred bucks.  I am pursuing this on the
principal.  My radio is legal for me to own, and I am tired of the
harassment from university police.
 
Please send your comments to me at mudaw@ecom.ecn.bgu.edu.


[TELECOM Digest Editor's Note: First, and most important, I am not an
attorney, and you are not my client. I will suggest that depending on
how strongly you feel about the principles involved here and getting
your equipment returned, you *should* consult an attorney who 
specializes
in communications law, preferably in your community if possible, 
although
quite a few (most?) of those people are in practice in Washington, DC
and environs. We do have attornies whose practice is specialized in 
the
area of federal communications law on the Digest mailing list, and
perhaps one or more of them will respond to you directly at least once
on a pro-bono basis offering some suggestions or help. My feeling is
the cost involved for *good* legal representation in this area will
be far in excess of the value of the equipment involved. This will 
have
to be your decision in connection with any discussions you have with
an attorney who is competent to assist you. I cannot do so. Good luck
with this. Perhaps other Digest readers will have suggestions also.  
PAT]

------------------------------

From: Bill Parrish <bparrish@bp700.rose.hp.com>
Subject: Old Rotary Service Question
Date: Fri, 13 Jan 95 7:58:32 PST


Pat's reply to the thread about scanners and cordless phones dealing
with party lines reminded me of something I had always wondered
about.

In the early 70s, I went to UCSB, and we were serviced by GTE in the
dorms.  Occasionaly folks would decide to "share" a phone connection
by making their own patches into terminal cabinets ... resulting in an
illegal but effective party line arrangement.  I recall that if the
phone had the wrong type of filter in it that you would sometimes get
the "pinging" sound rather than a vigorous "ring" when an incoming
call came in.

But there was a second funny thing about these "extensions" that was
rather odd ... you sometimes could not make long distance calls  on
them ... and that always seemed odd to me.  If I recall right, there
was some sort of a movable pin on the back of the dial that could
be put into one of several (three?) positions, and if you moved
the pin, it would enable the long-distance capability.  Could someone
explain how that worked?  (I could be remembering wrong ... it's been
a long time, but I always wondered how that worked).



Bill Parrish (916) 785-4986
M6KV      Hewlett Packard 
Systems Technology Division
8000 Foothills Blvd.
Roseville, CA 95747-5596 
HPDesk: Bill_parrish@hp5200.desk.hp.com
Unix to Unix: bparrish@hprpcd.rose.hp.com
Fax:  (916) (or TELNET) - 785-3096  

------------------------------

From: mkelly@gabriel.resudox.net (Mark Kelly)
Subject: Call Overflow Question
Date: 13 Jan 1995 22:38:58 GMT
Organization: Resudox Online Services


I have question for the telephony wizards out there.

A single number DN #1 has been assigned to a trunk group (say a T1, 24
channels). When all 24 channels are busy, its desirable to route all
incoming calls to the DN #1 to another number (DN #2).

Can anyone think of a way to do this that doesn't involve adding a
extra trunk group at the switch and pointing it to the second number.

Any suggestions or hints would be welcome.


Mark Kelly                        
Advanced Multi-Point Conferencing 
320 March Road, Suite 102         
Kanata, Ontario  K2L 1Z8                           
1-800-900-4249 (Reservations)     
1-613-592-5752                    

------------------------------

Date: Fri, 13 Jan 1995 19:33:42 EST 
From: Paul Robinson <paul@tdr.com>
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
Subject: 360 Degrees of Jumping the Gun


I decided to check Pat Towson's comments about the 630 area code in 
Chicago.  I first tried 1-700-555-1212 and it told me I have AT&T.

I dialed 1-630-555-1212 and when asked what city, I asked the operator
if it was the Chicago operator, and she said yes.  I realized I really
didn't have a reason to call anyone there.

So, next I decided to see if the new area codes are in place here, and 
dialed 1-360-555-1 

Oops, the phone times out on me!

Now, for the fun part.  I dial 611 and explain that I *can* call 1-630 
but *can't* call 1-360 and the agent says "It must be in your phone."

Yeah, right.  I explained that I have dialed the number by going 
through 
1-800-CALL-ATT and using a calling card.  

I explained that the same thing happens from other phones, on 
different 
lines.  

She put me on hold and when she came back she said that there is a 
routing problem, and she'll write up a trouble ticket.   We'll see 
what 
happens.

It must have been difficult (knowing my trouble with Bell Atlantic)
because I got a return call a few minutes ago, about an hour after I
placed the call to 611.

According to the person calling me, the "official" date that area code 
360 goes into effect isn't until tomorrow, which is why Bell Atlantic 
is 
not accepting calls placed to that area code yet.

So, if the statment is correct, those places that are accepting calls
to the 360 area code are actually "jumping the gun".

------------------------------

From: routers@halcyon.com
Subject: FAQs on Campus Connectivity
Date: 13 Jan 1995 12:14:06 GMT
Organization: Northwest Nexus Inc.


        NEW ANSWERS FOR FAQs ON CAMPUS NETWORKS AND CONNECTIVITY

This posting may be freely distributed to Internet and commercial
online sites.

Date:     January 12, 1994

Keywords: UTP distance standards, campus networks connectivity,
          ethernet, wireless, LAN, microwave, repeaters, video 


1.  QUESTION:   What is the maximum bandwidth that 4-wire copper
                UTP can handle in campus environments?
    ANSWER:     ---E-1 up to 2.5 miles (4 km)

2.  QUESTION:   What is the longest distance that 4-wire copper
                UTP can transmit at T-1 band width?
    ANSWER:     ---5 miles (8 km), up to 7 miles (11.2 km) with 
                   a repeater 
                
3.  QUESTION:   Can you transmit data, voice, and video across
                4-wire UTP at the same time without cross-talk?
    ANSWER:     ---Yes
    
4.  QUESTION:   What is the maximum distance that ethernet at
                10 Mbps can be extended?
    ANSWER:     ---1500 ft (495 m), up to 3000 ft (990 m) with
                   repeater
                   
5.  QUESTION:   Is there a wireless solution that would allow a
                campus to connect all buildings together, and
                allow any PC or laptop computer on campus to
                communicate, even if they move about the campus?
    ANSWER:     ---Yes.  One solution allows building -to-
                   building connections up to 6 miles (9.6 km), 
                   and allows any PC or laptop to be on
                   line.  It operates at 2 Mbps, has SNMP, and
                   requires no FCC licence.
                   
6.  QUESTION:   Are there any wireless solutions at 10 Mbps for
                LAN-to-LAN connections? 
    ANSWER:     ---Yes.  A microwave solution allows LANs to
                   connect up to 5 miles (8 km).  This same
                   system has options that will allow voice,
                   data, and video at the same time, in either
                   4 -T1 slots, or 8 -T1 slots.  The 8 -T1
                   version can handle 192 voice-grade circuits.


For further information and product data sheets, please contact
Router Solutions (routers@halcyon.com), or check our FTP site:
        ftp.halcyon.com   /pub/local/routers

------------------------------

From: TELECOM Digest Editor <telecom@eecs.nwu.edu>
Subject: Would You Believe More Rain on the Way?
Date: Sat, 14 Jan 1995 08:00:00 CST


Listening to WNIB on the radio this Saturday morning as I work on
this issue ... the eight o'clock news says 'up to six more inches
of rain due in California throughout the weekend ... more evacuations
probably will be required ...'

Well, good luck and my best regards, folks. It seems like the people
in California spend all summer burning the place down, then spend
all winter enduring mud slides and flooding. We are getting a lot
of rain here today also, but the only effect has been to melt all
the snow which had accumulated and leave some *huge* puddles of water
to navigate at curbs where the street sewers are plugged, etc.

Have the floods in California affected telephone service to any 
extent?


PAT

------------------------------

End of TELECOM Digest V15 #31
*****************************

                                  
