Since 1991, the ITU-T Study Group 14 (previously SG XVII) has worked to develop a recommendation for duplex modems operating over 14,400 bit/s termed V.34. The US supports this effort through the Telecommunications Industry Association (TIA) TR-30.1 committee.
| Symbol Rate | V.34 usage | Low Carrier | High Carrier |
|---|---|---|---|
| 2400 | required | 1600 | 1800 |
| 2743 | optional | 1646 | 1829 |
| 2800 | optional | 1680 | 1867 |
| 3000 | required | 1800 | 2000 |
| 3200 | required | 1829 | 1920 |
| 3429 | optional | 1959 | 1959 |
V.34 Modem Capabilities:
Current modems automatically select among 6 or more modulation types. V.32bis includes Annex A as one of the specifications that defines the procedures for automatic interworking between V.22, V.22bis, and V.32 modems. V.32 and V.32bis use the same negotiation process, so their automatic interworking is already defined. However, the interworking defined in Annex A is based on the characteristic tones of each modulation start-up sequence. Detecting tones is time consuming and not a very extensible procedure.
V.34 modems will include parts of new recommendation being developed - V.8 (previously V.id). V.8 describes a faster way for two V.34 compliant modems to handshake. One of the goals of the V.8 recommendation is to complete the entire startup handshake sequence within 5 seconds. A typical V.32/V.32bis startup sequence requires about 16 seconds.
V.34 modems will connect to each other at least 10 seconds faster than existing V.32bis modems. Both V.34 and V.32bis modems require a few additional seconds to negotiate error-correction and data compression protocols.
Then, the answering V.34 modem responds to the CM with a Joint Menu (using V.21 high band modulation) indicating the common capabilities of the modems at each end. Finally, after the joint capabilities are determined, a probing signal is passed between the modems to identify the impairments present in the telephone channel. With the results of the probing signal(s) the modem receivers and transmitters (in each direction) will train-up, utilizing the modulation techniques requested in the CM/JM exchange.
The personal computers of Apple, IBM, and compatibles, use EIA/TIA-232 compatible semiconductors (typically UARTs) with character-oriented communications software that does not provide reliable operation at data rates above 20,000 bit/s. In order for V.34 modems to be reliably utilized, a new approach to the digital interface to the computer will be required. Possible solutions include:
1. Use EIA/TIA 530A (specified in V.34). Backward compatible to EIA/TIA-232, it supports data rates to 2.1 Megabits per second (mbit/s).
This approach is a candidate for high speed serial communications interfaces on communications equipment such as front end processors, T1 multiplexers, routers, and similar communications equipment. It can also be adapted to support some "V.35" interfaces. Users should be cautious as many "V.35" implementations do not support the control signaling (DTR and DSR) to provide good switched network operation.
2. Use the electrical characteristics of V.10 (also specified in V.34). V.10 supports data rates up to 100 kbit/s and is electrically compatible with TIA 232. This familiar approach is the easiest for the user, but potentially the most problematic as well. PC serial ports already have problems supporting data rates over 20 kbit/s.
3. Use the IEEE 1284 standard for the bidirectional parallel port. This has a large installed base in personal computers but is somewhat dependent on the manufacturer for proper implementation. Xircom and Microcom modems provide this interface.
4. Connect directly to the PC via the PCMCIA interface. There are a large number of PCMCIA V.32 modems currently available.
5. Connect directly to the PC AT bus via a proprietary card. This solution is endorsed by Hayes, Codex, and others.
Approaches 4 and 5 support existing and emerging interfaces available on most personal computers. It is likely that manufacturers will need to provide at least approaches 1, 2, and 5 in the near term, and 4 when it is practical to fit the V.34 technology in a PCMCIA form factor.
All of the examples, except #2, require new software drivers to support the new physical interfaces. This is desirable as the new drivers can be designed to support more efficient communications with the host system rather than supporting character based communications.
1) Proprietary V.fast implementations that offer higher data rates and allow for upgrading to V.34 when it is complete. Unless you upgrade them, these modems will only be able to connect at speeds up to 14.4, and to other same-make modem models.
2) High data rate extensions to V.32bis, such as V.32terbo. Because these are simple enhancements to an existing modem specification, they will remain low cost, high data rate alternatives.
Type 1 - Proprietary V.fast implementations. Codex, a division of Motorola, announced a proprietary "326XFast" in April 1992 for $1395.00. This product operates at 24,000 bps and uses Codex proprietary implementations of several of the possible techniques proposed for V.34. Codex has promised US purchasers a kit for the customer to upgrade 326XFast to support V.34 compatible operation up to 24 kbit/s, when the recommendation is complete.
The success of this product forced other vendors to create alternatives prior to the completion of the V.34 recommendation. Penril Datability Corp., Racal Data Communications, Hayes, and General DataComm, have announced proprietary high data rate dialup modem implementations in competition with the Codex 326XFast.
In late 1993, Rockwell announced a chip set implementation of their version of V.fast operating at data rates up to 28.8 kbit/s, which they termed V.Fast Class (V.FC). This implementation, supported by multiple manufacturers, does not use the V.8 handshaking mechanism. Therefore it cannot be compatible, without software or PROM modification, with the future V.34 standard.
Each of the proprietary implementations of V.fast offers the user higher data rates in advance of V.34 and probably requires (for future compatibility) that the user upgrade these implementations to V.34 when it becomes available.
Type 2 - High data rate extensions to V.32 bis. A group of vendors led by AT&T proposed in September 1992 to a CCITT SG XVII Rapporteurs meeting, a simple extension to the existing V.32bis technology that maintained the same symbol rate (2400) and added two new constellations of 256 points and 512 points to support data rates of 16,800 and 19,200 bps respectively. The Rapporteurs group, not wishing to lose focus on V.fast, did not accept this proposal. Subsequently, AT&T has termed this technology V.32terbo.
Since constellations with a large number of points are very sensitive to distortion, AT&T also proposed a novel technique termed nonlinear encoding (one of the optional techniques included in V.34) to improve performance when such large constellations are used. Nonlinear encoding does not require additional processor resources in the modem. The AT&T proposal utilizes the existing V.32/V.32bis negotiation procedure by implementing two unused states to signify 16,800 or 19,200 bps operation. This reduces compatibility problems with the installed base of V.32 and V.32bis modems. Since the symbol rate (2400) remains the same, it typically does not require a faster processor to implement. For these reasons V.32terbo will continue to be a low cost add-on to existing V.32bis products.
Study Group 8, which approves the G3 facsimile recommendations, is considering implementing a half duplex V.34 to reduce the complexity and costs of a facsimile modem. In addition, it is possible that a lower data rate full duplex modem (possibly V.22 [1200 bps] or V.22bis [2400 bps]) could be used for the lower data rate negotiation phases of a facsimile connection. Currently, the low data rate negotiation phase (T.30) is accomplished using V.21 (300 bps half duplex).
Based on the current SG 8 schedules, extensions to G3 to include V.34 could be introduced before the end of 1994. However, completion of G3 recommendations would not occur until 1995 at the earliest.
With the recommendation technically completed, it will be presented to the June 1994 SG 14 meeting for approval. When approved there (which is very likely, but there may be some technical changes that occur), it will be presented to the ITU membership for final approval (normally this does not cause any changes). Current plans call for V.8 to separately follow same approval path.
Users should expect an even longer period from first implementations to multi-vendor interworking than has occurred in the past. In the author's experience, past multi-vendor modem interworking issues have been resolved over a 6 to 12 month period after first production shipments commence. Integration of V.34 into existing communications systems will pose new problems (and opportunities) because of the need to utilize different interfaces to support higher data rate communications. V.34 will be a remarkable technical achievement reaching near the highest possible data rate of a telephone line. But V.34 will not be "V.last".
The need to create new ways to use the ubiquitous, and still expanding, worldwide digital telephone network with analog interfaces, will continue to drive new modem requirements for the foreseeable future. In fact, the V.34 Rapporteurs group have already noted enhancements that they do not have the time to consider. They suggest that such enhancements could be implemented in "V.34bis"!
Has the marketplace made itself heard over the din of proprietary interests in V.34 standards meetings? We should know shortly.
Ken Krechmer has been the principal in ACTION Consulting, Palo Alto,
CA for over 13 years.
ACTION Consulting
(www.csrstds.com)
assists in the development
of new WAN communications products by identifying and specifying
emerging feature requirements and new market/technology segments.
Krechmer participates in ITU-T Study Group 14 (data communications
over the PSTN), Study Group 15 (ISDN), Study Group 8 (facsimile
and telematic services); also TIA TR-30 (data communications),
TR-29 (facsimile), TR-45, (cellular), TR-46 (PCS), TR-41 (digital
DCE), and ATIS T1 committees. He is the technical editor of
Communications Standards Review (Palo Alto, Ca.), the only
technical journal reporting on standards work in progress in TIA and
ITU-T. Clients include major communications equipment suppliers and
carriers worldwide.
Page 13 had a full-page ad for Mustang Software (www.mustang.com).
Page 14 had ads for Floreat (www.floreat.com), the Pacific Exchange BBS, and DC to Light.
Page 15 had a full-page ad for Clark Development Company.
Page 16 had ads for Tiger Team and Hyperworks.
Page 17 had ads for Slaygor's Domain, Terminal One, Weasel Den 2, and the Black Rose BBSs.
In recent years, BBS packages were limited to what the package author thought would be nice features to have. Most Sysops wanted just a little bit more. Although some Sysops don't mind running BBS software right out of the package, there are a few of us who feel it is important to have a BBS that looks and feel different than any other. To those of us, only changing a few menus, or just coloring prompts in different ways, limited what we could change on the software we were running.
The BBS world was changed forever when Clark Development Company, Inc. released version 15.0 of their PCBoard BBS software. Sysops now have the ability to not only change menus and prompts, but to have total control over what the PCBoard BBS software will do.
PPL source code commands resemble the BASIC programming language. The PPLC itself was written in C++. Because the extensions you create are integrated with PCBoard, it gives you the assurance that if your BBS runs, whatever program you write will run. The PPLC handles all the overhead of a BBS application, including all communication routines. All you will need to worry about is writing, reading, and processing your BBS files.
The only real limitation you will have with PPL will be your imagination. Although you cannot write a complete BBS package, due to a 30.7k limit in PPE size, you could write different modules to interface the existing PCBoard with your PPEs. You could write modules for messages, the file area, and the main board module to process all the BBS commands as you see fit.
The flag PPE is an example of the power of the PPLC. FLAG.PPE came to exist as a dare to David Terry (PCBoard GURU). At One BBSCON (a national Sysop conference), David was dared to come up with a way to flag files for downloading that would be better than any other BBS software's method. What he came up with was a way for users to flag files using nothing but the space bar and the enter key. Which needless to say, is one of the best ways of flagging files on any BBS software.
Rotating Screens: A Sysop can use a PPE to toggle the display screens the callers see each time they call. You could set up your BBS so that if a caller calls three times in a row they would get one screen that says "Auto-Sensing ANSI/RIP," and the next time it would say "ANSI & RIP detection process", and so on. By using a PPE, you avoid the need for an external third-party program that can slow down the login process, and might not work on your particular system configuration.
Although most BBS packages have built in automatic ANSI/RIP detection, PCBoard, PPLC, and a little imagination allow you to not only automatically sense ANSI and RIP, but allow you to display an unlimited number of different screens once detection has been achieved.
PCBoard has so many message reading options that it is hard for a Sysop to figure out which options to put on the main menu. Now you can have just one option on the main menu and create an entire sub-menu that includes every option for reading messages. Besides processing regular PCBoard commands, .MNUs can also "redirect" commands to perform other options.
As an example, if you wanted the user to be able to "Read mail in All conferences since last login", you could create a simple (S)ince command to do a 'R;A' for your users. Another example would be the "Read Your mail Since last logon" which could be interpreted as 'R;Y;S' command which would alleviate the user from having to read messages addressed to all other users, by just using a (M)y mail command.
My experience in programming is limited. In spite of that, I have been able to write a few different PPEs that make my board different from any other board. I have found PPLC very easy to work with. This shows that even those of us who are somewhat limited in programming knowledge can still take advantage of such a feature. My hat is off to Clark Development Company, Inc.
Besides the regular TV audio and video signals, Action 36 broadcasts data that can be captured with the ITC TeleText decoder card. As with other television broadcasts, most of the high-speed wireless data broadcasts are free to the public, paid for by advertisers.
International TeleText Communications, Inc. (ITC) designs and manufactures the equipment to encode, insert, and decode data into TV video signals. Data is multiplexed into TV 36's signal at 48,000 baud. ITC's TeleText Decoder card can handle data transmissions at rates between 14K and 114K baud. The card is a single (8 bit) PC card that automatically detects and adjusts to the data rate of the broadcast station.
TeleText resides in the part of the TV picture called the Vertical Blanking Interval (VBI). VBI is that black line you see when the TV picture rolls up and down the screen. Your TV set uses the VBI as a synchronization signal to hold the picture and keep it from rolling. You can see the millions of tiny white dots in the VBI line by adjusting the vertical hold on your TV set. As digital chip technology became faster and cheaper, inserting and decoding data within this vacant TV bandwidth made ITC's technology a cost effective wireless solution. Today, ITC's consumer TeleText decoder card is sold in Bay Area stores for under $200.
ITC's wireless data network transmits USA Today Decisionline news, originating from Gannett Publishing. Also broadcasted are (15 minute delayed) complete NYSE, AMEX, and NASDAQ stock market quotes.
The TeleText decoder card comes with software to give you full access to these ad-supported data broadcasts, 24 hours a day. The software is DOS-based and can capture data in the background, under both OS/2 and Windows. Demo versions of the ITC software are free downloads from the ITC support BBS.
Page 19 had ads for Just Computers!
(www.justcomp.com);
and the Party Line
(www.partyline.com)
and Body Images BBSs.
Last year, I was planning a trip to London via Paris with some friends. Like many people needing information, I sought out a travel bookstore. I spent at least an hour browsing through travel books, examining maps, and trying to learn as much as possible about my destinations. I ended up spending over $50 on various travel books and maps before I got out of the store. What I really wanted, was just to talk with someone who had been there recently - someone who could recommend restaurants, hotels, or give me some tips about getting around.
When I returned from my trip, I had information that others, like myself, would benefit from. That's when I decided to create a BBS system dedicated to that purpose. I believe that BBS systems like the Travel Connection! can provide a valuable supplemental information source for travelers. Not affiliated with any travel agency, the Travel Connection! is the "back roads" of information for the independent traveler.
"Coach" users can download some files, read messages in all conferences, send and receive private email, and access State Department travel information. Subscribers can advertise on the Trader Board, submit and download files from the Travel Photo Library, and access tourist information. Subscribers also have full file downloading capabilities. Various subscriber rates exist from "Ambassador" to "World Traveler".
From talking with other travelers, I believe The Travel Connection! will provide a valuable service for the independent travelers. A number of conferences are available for San Francisco, the Bay Area, and elsewhere in California. If you have a favorite local restaurant or getaway spot, share it with everyone through the Travel Connection!
Page 20 had an ad for the San Lorenzo User Group.
Pages 21 though 28 had detailed listings of Bay Area BBSs.
Page 24 had ads for UNIROM (www.unirom.com), Atlas BBS/Internet Service (www.gilroy.com), and the UFO BBS.
Page 29 had a full-page ad for PC-TEN
Page 30 (back cover) had a full-page ad for
TeleText Communications.
End of Issue 12. Go back, or to
Issue 13, or to
Mark's home page.