Return-Path: Received: by massis.lcs.mit.edu (8.7.4/NSCS-1.0S) id JAA23479; Thu, 30 Jan 1997 09:08:34 -0500 (EST) Date: Thu, 30 Jan 1997 09:08:34 -0500 (EST) From: ptownson@massis.lcs.mit.edu (TELECOM Digest Editor) Message-Id: <199701301408.JAA23479@massis.lcs.mit.edu> To: ptownson@massis.lcs.mit.edu Subject: TELECOM Digest V17 #25 TELECOM Digest Thu, 30 Jan 97 09:08:00 EST Volume 17 : Issue 25 Inside This Issue: Editor: Patrick A. Townson UCLA Short Course on "Turbo Codes" (Bill Goodin) FCC Forum on Telecom Network Congestion (oldbear@arctos.com) Massachusetts Area Code Splits (John Grossi) Re: Alternate Directory Providers (Joseph Singer) Book Review: "Focus on the Future: Migration Strategies" (Rob Slade) Pye Philps Broadcast Address Needed (Charles H. Beard) X2/56K: What if They Gave a War and Nobody Showed? (Dave Sieg) Re: Using a "700" Number to Dial Around (Al Hays) Re: Great European Renumbering Proposal (Hendrik Rood) 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: * ptownson@massis.lcs.mit.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: Post Office Box 4621 Skokie, IL USA 60076 Phone: 847-329-0571 Fax: 847-329-0572 ** Article submission address: ptownson@massis.lcs.mit.edu Our archives are located at mirror.lcs.mit.edu. The URL is: http://mirror.lcs.mit.edu/telecom-archives They can also be accessed using anonymous ftp: ftp mirror.lcs.mit.edu/telecom-archives/archives A third method is the Telecom Email Information Service: Send a note to tel-archives@mirror.lcs.mit.edu to receive a help file for using this method or write me and ask for a copy of the help file for the Telecom Archives. ************************************************************************* * 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. * ************************************************************************* Finally, 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: Bill Goodin Subject: UCLA Short Course on "Turbo Codes" Date: Thu, 30 Jan 1997 09:52:00 GMT On April 23-25, 1997, UCLA Extension will present the short course, "Turbo Codes: Principles and Applications", on the UCLA campus in Los Angeles. The instructors are Dariush Divsalar, PhD, Jet Propulsion Laboratory; Sergio Benedetto, PhD, Politecnico di Torino; Guido Mortorsi, Politecnico di Torino; and Fabrizio Pollara, PhD, Jet Propulsion Laboratory. Turbo codes were introduced in 1993 and are considered among the most important developments in coding theory. Researchers around the world have been able to extend the basic idea to other forms of code concatenations, with various applications to transmission over fading channels, band-limited satellite channels, and channels with intersymbol interference. A turbo code is formed by two simple convolutional codes separated by an interleaver. The decoder consists of two Soft-Input Soft-Output (SISO) modules connected by an interleaver and a deinterleaver. This course addresses fundamentals of turbo codes; understanding of the principles governing the code behavior; extension to multiple turbo codes, and iterative decoding; design of a turbo code for various throughputs and modulations such as M-PSK, M-QAM; implementation of a turbo decoder by using the Add-Compare-Select operations and lookup tables similar to those used in the implementation of Viterbi decoders; extensions of turbo coding concepts to other forms of concatenation with interleavers such as serial and hybrid concatenation; applications to space communications, digital direct broadcast satellite services, CDMA, and virtually any data communication system that can tolerate a delay due to an interleaver size of at least 250 bits (delay is proportional to the interleaver size divided by the data rate). This is a new subject area and the potential applications of this new coding scheme are potentially broad. Engineers working in all aspects of information transmission technology, as well as research scientists and academics, should benefit from the material presented in the course. The analytical details are kept to a minimum and no algebraic tools are required. The course fee is $1295, which includes extensive course materials. These materials are for participants only, and are not for sale. For additional information and a complete course description, please contact Marcus Hennessy at: (310) 825-1047 (310) 206-2815 fax mhenness@unex.ucla.edu http://www.unex.ucla.edu/shortcourses This course may also be presented on-site at company locations. ------------------------------ Date: Thu, 30 Jan 1997 08:38:01 -0500 From: The Old Bear Subject: FCC Forum on Telecom Network Congestion Forwarded to the Digest: Date: Thu, 23 Jan 1997 22:47:26 -0500 From: James Love Subject: Today's FCC Forum on Bandwidth (and network congestion) (fwd) Today's FCC Forum on Bandwidth and network congestion was pretty interesting. The first panel looked at the current deployment of xDSL, cable modems and wireless alternatives, and it was pretty sobering. Basically, for residential consumers, these technologies are not being deployed anytime soon, in significant numbers. Stagg Newman from Bellcore gave a nice description of the practical problems in deployment for the best known new technologies. His video of the speed of a cable modem using a reasonable assumption regarding cable network use showed how much slower this technology is likely to be when and if it is deployed in large numbers. The wiring problems for cable and ADSL were substantial. Les Vadasz from Intel expressed that company's frustration with the pace of deployment, and then asked the participants to "forget about the 1st million customers, tell me when will we get the second million" broadband customers? Apparently, not for a long time. I take a lot of flak for spending so much time on ISDN pricing, but after today's presentation, it is hard to see what else can be deployed broadly in the United States over the next seven years (an eternity in Internet time). The second panel ended up talking about various technologies and economic incentives to take POTS, ISDN or other digital calls off the circuit switched network at the central office, and send the data via packet switched networks to the ISPs. PacBell wants to charge ISPs about $45 per "port" for the equivalent of an incoming and modem for this service, which is more than what they pay now for POTS and a modem or ISDN. The phone companies want to impose new fees on the ISPs (which they compete against), in order to more or less force them to switch to the packet switched transport from the central office to the ISP. We suggested they encourage deployment by offering cheaper ISDN or other digital services, when they use the packet transport. An ISP might pay $45 for the line, if he could offer a higher speed digital connection to its consumers, particularly if it wasn't metered (as many local ISDN tariffs are now). The LECs are already charging way too much for ISDN, for example, and selling it to no one, so this might provide a win-win solution, giving consumers higher bandwidth, while moving the call off the circuit switched network. There was a fair amount of discussion about the fact that ISPs in general are typically set up so that only 5 to 10 percent of consumers can connect at any one time, and this is less than the 14 percent that the residential voice network is supposed to accommodate, raising the question -- how can this lead to congestion in the residential telephone network? We said the average duration of a call was meaningless in itself, without data on the number of calls and how they are distributed over the day. (1 20 minute call is hardly more of a burden than 20 3 minute calls). PacBell countered by offering California statistics that say voice users consume an average of 22 minutes of network resources per day, compared to 62 minutes for Internet users -- nearly three times more. But there was not much data on how Internet calling differs from the voice calling. For example, do Internet calls have longer peaks, and do they occur in hours when the voice network isn't being used? We suggested PacBell provide the FCC with data from their own ISP showing the percent of subscribers that can connect at any one time, and compare this to capacity of the PacBell voice network. Kevin Werbach asked what type of information the FCC could provide that would resolve some of these questions, and we asked for data on ISP usage, including both average minutes per day and the distribution of that usage over the day, and the ratio of customers to incoming lines. We also wanted to see better data on how voice and modem use (time, and distribution of use over the day) on the public switched network, and how these have changed in the past few years. I also suggested that the FCC create market incentives to get the LECs to deploy any kind of digital services. (ISDN, xDSL, anything). Since the LECs are basically monopolies in their own service areas, I suggested making the major LECs (assuming they don't all merge with each other) compete against each other for deployment, and have the FCC reward LECs that had the highest penetration of digital lines to residential consumers, and punish those that have the lowest, by tying deployment to Universal Service fund contributions (or something else that really mattered) to a ratio of that company's penetration rate to the average penetration rate. This would force the LECs to compete against each other. I thought this would leading to some surprising changes of heart among the LECs. The FCC staff wasn't too receptive to this proposal. Our prepared comments are on the web at http://www.essential.org/cpt/isdn/bandwidth.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ James Love / love@tap.org / P.O. Box 19367, Washington, DC 20036 Voice: 202/387-8030; Fax 202/234-5176 Center for Study of Responsive Law Consumer Project on Technology; http://www.essential.org/cpt Taxpayer Assets Project; http://www.tap.org ------------------------------ From: John Grossi Subject: Massachusetts Area Code Splits Date: Thu, 30 Jan 1997 3:47:27 EST The Massachusetts PUC yesterday decided to carve area codes 617 and 508 up instead of overlay as NYNEX had suggested. The original plan was modified by the PUC so that no community was split between area codes. So in May 1998 Massachusetts will go from three to five area codes (413 in Western Massachusetts). The exact implementation plan was not discussed in The Boston Globe's front page article. -John Grossi (there is a disagreement between the Globe's Map and a the list of towns along the 508/978 line in Central Mass. i.e. East Brookfield is listed as switching and on the map it's shown still in 508) Here's the break down: staying in 617: Boston (all neighborhoods) Brookline Cambridge Chelsea Everett Milton Newton Quincy Somerville Winthrop (this amounts to the inner core of Boston) switching from 617 to 781 Abington Arlington Bedford Belmont Braintree Burlington Canton Cohasset Dedham Duxbury Halifax Hanover Hanson Hingham Holbrook Hull Kingston Lexington Lincoln Lynn Lynnfield Malden Marblehead Marshfield Medford Melrose Nahant Needham Norwell Norwood Pembroke Plympton Randolph Reading Revere Rockland Saugus Scituate Sharon Stoneham Stoughton Swampscott Wakefield Waltham Watertown Wellesley Weston Westwood Weymouth Whitman Winchester Woburn (a ring around Boston, in some places one town wide) switching to 978 from 508 Acton Amesbury Andover Ashburnham Ashby Athol Ayer Barre Berlin Beverly Billerica Bolton Boxborough Boxford Carlisle Clinton Concord Danvers Dracut Dunstable East Brookfield Essex Fitchburg Gardener Georgetown Gloucester Groton Groveland Hamilton Harvard Haverhill Hubbardston Hudson Ipswich Lancaster Lawrence Leicester Leominster Littleton Lowell Lunenburg Manchester Maynard Merrimack Methuen Middleton Newbury Newburyport New Salem North Andover North Reading Orange Peabody Pepperell Petersham Phillipston Princeton Rockport Rowley Royalston Salem Salisbury Shirley Sterling Stow Sudbury Templeton Tewksbury Topsfield Townsend Tyngsbourgh Warwick Wayland Wendell Wenham Westford Westminster West Newbury Wilmington Winchendon (basically Essex County, Northern Middlesex and the northern half of Worcester County (a line running about 10 miles south of SR 2) staying in 508 (~150 towns) major towns: Worcester, Framingham, Natick, Brockton, Fall River, New Bedford, Plymouth, Hyannis, Vineyard Haven, Nantucket. (The southern half of Worcester County, Bristol County, the southern half of Plymouth County, and all of Banstable, Dukes, and Nantucket Counties (Cape Cod and the Islands)) ------------------------------ Date: Wed, 29 Jan 97 16:50:43 PST From: dov@accessone.com (Joseph Singer) Subject: Re: Alternate Directory Providers Mark J. Cuccia wrote: > Lately my customers have been informing me that Directory Assistance > is giving them an outdated, three-year-old number for our business. > As it happens, this number isn't in the NYNEX database, but I've > determined that those getting this bad information are Sprint/MCI > customers probably reaching some contract DA provider. > Who are these providers? And how does one reach them to remove an > outdated or incorrect listing in their DA databases? On a slightly different note you may know that directory listings are available through several sources on the web including Four11.com (http://www.Four11.com/) and switchboard.com (http://www.Four11.com/). I'd like to know how accurate their listings are and where they obtain the information that they disseminate. Most of the listings that I've checked from switchboard.com have been correct, but the same listing when checked with four11.com many times turns up no listing. I'd be interested in anyone else's findings on this. Also with both of these services they have limited ability to search out e-mail addresses. Joseph Singer Seattle, Washington, USA dov@accessone.com http://www.accessone.com/~dov PO Box 23135, Seattle WA 98102 USA ------------------------------ Date: Wed, 29 Jan 1997 13:32:37 EST From: Rob Slade Subject: Book Review: "Focus on the Future: Migration Strategies" CBMIGSTR.RVW 961019 "Focus on the Future: Migration Strategies for Emerging Technologies", Bellcore, 1996, 1-57305-084-9, U$695.00 %A Bellcore %C Room 3A184, 8 Corporate Place, Piscataway, NJ 08854 %D 1996 %G 1-57305-084-9 %I Bellcore %O U$695.00 +1-800-521-CORE +1-908-699-5800 fax: +1-908-336-2559 %O llavoie@notes.cc.bellcore.com mgordon2@notes.cc.bellcore.com %T "Focus on the Future: Migration Strategies for Emerging Technologies" Bellcore must have great plans for this one. Juan kept calling and asking if I had had time to review it yet, implying that I needed the "exposure" such a review would provide. Well, Juan, let this be a salutary lesson on what happens when you bug reviewers and your product is mediocre. I don't think either of us are going to get any benefit out of this "exposure". First, while it does warn you that it needs twenty-seven megabytes of disk space (I was able to fill out two pages of a densely packed questionnaire and still get halfway into the "Scientific American" before it was done loading), it doesn't say anything about the requirement for a 256 colour driver, which sent me scurrying around for old system disks. Once I got it running, it was pig slow. Now, I don't have an absolutely state of the art machine for testing, but it's still fairly common. The program lost track of itself several times on the way through, lost track of where I had been in the program (frequently), occasionally entered strange graphics modes, failed to respond to selections (incidentally, the "Return" and "Enter" keys are not handled identically), and finally crashed the machine. (When I restarted, it had lost all data about how much of the "training" I had already been through.) It would be wrong to say that this program is a page turner. Instead, it is a page turner through a complex and twisty little maze of mini-lessons. After a while they all begin to look alike. It's almost like an adventure game, in that you are never sure, when you click on one of the mandatory (and, oh yes! they are mandatory) links, whether you will find a single page, and then return to where you started, or go off through another huge subsection. All of which is probably beside the point, since the important thing is the information. There are four parts to the program. Two are sales brochures for advanced telephone services. One is an extremely simplistic guide to planning. The last module allows you to develop a plan--for the Westville County phone network. (By the way, when it comes time to deinstall the program, Bellcore cheerfully states that all you have to do is delete the files. What they don't tell you is that all the files were made read-only when they were installed. You remember where you put ATTRIB, don't you?) copyright Robert M. Slade, 1996 CBMIGSTR.RVW 961019 ====================== ROBERTS@decus.ca rslade@vanisl.decus.ca Rob_Slade@mindlink.bc.ca The client interface is the boundary of trustworthiness - T. Buckland Author "Robert Slade's Guide to Computer Viruses" 0-387-94663-2 (800-SPRINGER) ------------------------------ From: chb890@aol.com (CHB890) Subject: Pye Philps Broadcast Address Date: 29 Jan 1997 22:17:22 GMT Organization: AOL http://www.aol.com We are looking for help in finding the address and phone number of the PYE PHILPS Broadcast Div. that mfg. the low power F M Broadcast Transmitters ( 300 Watt ) ( solid State ). We are trying to change freq on one of the 3 we have to 89.1 and the books we have only show it will go down to 89.5. HELP ! Charles H. Beard chb890@aol.com 800 588 2774 Charles H. Beard CSSI / KZEE RADIO 206 Wiggs Lane FAX 888-868-1661 telco 817-596-8768 ext 208 cellullar phone 817-682-8218 pager 817-596-1000 num alpha por#t 817-596-1950 PIN 1000 e-mail chb890@aol.com W5FJC ------------------------------ Date: Wed, 29 Jan 1997 22:09:17 +0000 From: Dave Sieg Reply-To: dave@tricon.net Organization: Zeta Image, Inc. Subject: X2/56K: What if They Gave a War and Nobody Showed? Just an idle thought while watching the stormclouds gather for the coming 56KWar ... The nearly 3,000 small ISP's in the US have been responsible for getting millions of users onto the Internet, and have experienced firsthand the pain of non-interoperating "standards". Many of these ISPs have grown despite these obstacles, and are no longer so small! They have yet to exercise their power as any kind of coherent group, largely because they see each other as competitors. The whole 56K thing seems to be based on somebody at USR figuring out that since they've sold millions of consumers modems with flash-upgrade capabilities, they can in one slick move: (1) Convince consumers to spend $90 for an upgrade (which costs them almost nothing) which will then: (2) Place pressure on ISP's to buy expensive USR terminal equipment. While the technology is still far from proven in the field, and a standard is still 12-18 months away, WOULDN'T IT BE INTERESTING if ISP's "exercised their power" at least to the extent of saying: "This stinks! Show me something that works and is a standard, and I'll buy it, meanwhile I'm telling consumers they've been sold vaporware!" Of course the argument against this is that the technology DOES work (witness all the testimonials in this newsgroup, for example) ;) and that if MOST of the ISP's agree to hold fast, some young upstart will steal all the business by diving into 56K with both feet. Gee, would _I_ bet my entire business on such vaporware? I'd like to see a show of hands from ISP's ... anybody taking this seriously? ------------------------------ From: Al Hays Subject: Re: Using a "700" Number to Dial Around Date: Wed, 29 Jan 1997 09:24:22 -0600 Charles Holcomb (cholcomb@tpd001.dp.tpd.dsccc.com) wrote: > On of my relatives can not use her LD carrier's PIC code to dial > around her LEC for her long distance calls in her LATA. > I was told you can use a 1-700-xxx-xxxx to be able to dial around and > still use your prefered LD carrier. > Is this true, and why is it not mentioned by LD carrier's?? > What excatly is the "700" number used for?? In addition to the many uses that have been presented in the past few days, there are other uses as well. We have Sprint's VPN (Virtual Private Network) as our LD service. In our five major call centers nationwide we have dedicated T1 access to VPN. Sprint allows us seven-digit "desktop-to-desktop" dialing by accessing these VPN trunks, dialing a three-digit city prefix which we defined and Sprint input into our account configuration and then the four-digit extension number of the party on the other end. Sprint simply outpulses the four-digit extension to the switch on the other end and viola ... you're on the remote desktop. This is particularly handy since only one of the call centers is equipped with DID trunks. Our remote Service Offices and Regional Sales Managers across the country have switched VPN LD service. They can dial direct to the desktop on any employee located within one of the five call centers with dedicated service by dialing 1-700 and the seven-digit desktop code as above. The same is true of our VPN Foncards. Accessing the Sprint Foncard 800# (800-877-8000) and then dialing 0-700-xxx-xxxx will place the call direct to a VPN desktop as defined above. According to Sprint, dialing 1-700 from a switched location advises the LEC to "ignore this call and pass it unaltered to the LD carrier." The LD carrier would then have some predefined manner of handling the call ... which could include an intra-LATA dial-around. regs, Alan H. Hays The Mark Travel Corporation Senior Telecommunications Analyst 8097 N. Port Washington Road Voice:414-934-2600 Fax:414-351-5837 Post Office Box 1460 EMail: ahays@marktravel.com Milwaukee, WI 53201-1460 ------------------------------ From: hrood@xs4all.nl (Hendrik Rood) Subject: Re: Great European Renumbering Proposal Date: Thu, 30 Jan 97 04:44:09 GMT Organization: XS4ALL, networking for the masses In article , Telecom@Eureka.vip. best.NOSPAM (Linc Madison) wrote: > I've just been reading some documents from the European Union > regarding some proposed numbering changes in Europe, on a vast scale. > The full text of the proposal, in Microsoft Word for Windows format > (213K) is at: [snipped] > However, the "green paper" doesn't address the colossal code conflicts > that this proposal would create in France and Spain. For instance, > London +44-20 would become +344-20, but that conflicts with Bilbao, > Spain, +34-4-20... That number in Bilbao in turn would become > +334-4-20..., but it would then conflict with a number in southeastern > France, +33-4-420... [For those of you saying "London = 20?," area > codes 0171 and 0181 in London will un-split into area code 020 in the > year 2000, with 8-digit local numbers.] This particular example uses > only real numbers which exist or will exist within 3 years, so the > conflict is quite substantial. > In order to work the proposed scheme, there will need to be at least a > four-phase changeover, which must be followed sequentially. At each > stage, there will need to be a minimum of one year of permissive > dialing, followed by at least one year of intercept recordings. During the renumbering of the Dutch Telephony Numbering Plan the same type of code conflicts as you spotted in the European Commision plan were possible in the permissive dialling period. These problems has been resolved though by introducing a software feature in the switched called "numbering length analysis". I am currently preparing a comment on the plan (comments can be send to the EU up to februari 21st 1997) and looking after this issue. As far as my current investigation had let to results most of the numbering conflicts you have discovered can be resolved by introducing numbering length analysis in the digit analysis software resident in the international switches of the European countries involved . But I have not worked out if it is easy possible to adjust billing systems too. Nor maintenance and test systems. From what I have seen in press comments allready and heard in the market this plan is highly criticized. ir. Hendrik Rood Stratix Consulting Group BV, Schiphol NL tel: +31 20 44 66 555 fax: +31 20 44 66 560 e-mail: Hendrik.Rood@stratix.nl ------------------------------ End of TELECOM Digest V17 #25 *****************************