| |
Components of V.92
Handshake Sequence
Preliminary tests show that, on average, connect times are 30 percent to 40 percent faster with V.92 than with V.90. ISPs will benefit from the timesavings because they log millions of sessions every day. The quick connect V.92 feature works by “training” the client modem on the first call. Analog characteristics and digital impairment information are captured in a profile stored on the local disk drive or, for external modems, in RAM. The V.92 modem looks for this local profile and checks whether the server modem is V.92-capable. If it is, the V.92 modem proceeds with the quick connect handshake.
Quick Connect Theory of Operations
One of the main drawbacks of using the Internet over the public switched telephone network (PSTN) is the amount of time it takes to establish a connection to an Internet Service Provider (ISP). There are four steps for establishing a dial-up PPP connection. First, the host modem must dial the ISP telephone number and establish a physical link from the client modem to the server (ISP) modem. Next, the modems perform a handshake to compensate for the analog and digital impairments and connect at the optimum rate. Third, the modem establishes an error-free link using V.42, and finally, the host software performs the PPP login protocol. Typically, this scenario, from off-hook to PPP connection, takes 25–30 seconds to complete. Unfortunately, the time it takes to establish a physical link between the two modems through the PSTN is time-consuming and little can be done to speed things up. Nevertheless, it is likely that we can save a second or so here by qualifying dial tone for a couple hundred milliseconds (instead of 700–800 ms) and shortening the DTMF digit duration and inter-digit delay.
The analog channel consists of the local loop from the client modem to its local central office. The analog channel characteristics (equalizer taps and echo canceller taps) are saved in non-volatile memory from a V.90 (standard train) connection. Similarly, the digital characteristics are saved in nonvolatile memory. On subsequent calls to a fast train-equipped server modem, the client modem examines the answer tone to verify that the line conditions are similar to its saved parameters. If the parameters match, a fast connection is attempted. If they do not match, a regular V.90 handshake commences.
Implications and Usage Models
In the simplest application, quick connect allows users to go from launch to activity in a much shorter time than was previously allowed with traditional standard training times. This improves the user model, and makes the connection more transparent than before. As quick connect is deployed more widely, primarily in central site modems, a different user model can be conceived. With quick connect, the IP connection between the ISP and the client can be maintained, while the physical connection between the POP and the client modem becomes dynamic. When the client requires more information or makes an IP request, the modem quick connects with the central site without having to log on again. This frees up a port when the client is idle, yet allows the user to remain online. This requires changes in the client ISP software and the ISP host software, but allows greater central site port utilization. It allows users to remain virtually online for extended periods of time while using a switched-circuit connection.
What will quick connect do for me?
Very simply, quick connect will shorten the time it takes to make a connection by remembering ("training") the phone line characteristics and storing them for later usage. Typically, the modem handshake (all that noise you hear) takes from 25 to 27 seconds. Surveys indicate that people are quite irritated at this length of time. Quick connect will cut the modem handshake time in half for most calls, a significant improvement.
Will Quick Connect work for me while I'm on the road with my laptop?
Yes. Since quick connect actually "trains" the modem on the first call, all the following calls will be quick connects - faster handshake times. People usually make more than one connection from the same phone line (e.g. hotel) when they are traveling.
Modem-on-hold (MOH)
A large call and trouble generator for modems stems from users who do not disable call-waiting when online. A call-waiting signal looks to a modem-like a line disconnect, and depending on how the modem is configured, can often result in the modem hanging up. In some cases, users prefer this behavior, because they want to receive the call coming in. Unfortunately, the feature that is enabled for those who want the call is trouble for those who do not.
Call-waiting survival has been identified as another feature required in a next-generation modem standard. Communication between the server and client that enables a rational call-waiting survival allows the client to put the server on hold, or vice versa. The notable application for a Modem-On-Hold™ (MOH) allows the client modem (after seeing call-waiting and optionally processing the call-waiting caller ID), to put the server modem on hold for a short time (e.g., 4 minutes). This allows two callers to have a rational and unhurried conversation. Competitive solutions now allow only seven seconds. This is not enough time to answer, identify the caller, get a phone number, and politely terminate the call. The MOH method allows the server and client modem to negotiate a mutually agreeable time period in which the other remains on hold.
Modem-on-Hold/Call-Waiting Survival Theory of Operations
There are several different scenarios covered by the MOH capability:
1. Incoming Call accepted by local: modem is placed on hold
2. Incoming Call denied by local: continue with data
3. Incoming Call accepted by local: clear down data connection
4. MOH request denied by remote: restart data connection
5. MOH request denied by remote: clear down data connection
Case 1
In the case of call-waiting on the APCM (Client modem) accepted by the DPCM (Server modem). The APCM is interrupted by the call-waiting tone. The client issues a DTMF “D” in order to receive the call-waiting caller ID. From this, the APCM user decides that he wants to accept the call. The APCM and DPCM then negotiate the maximum time that the server will allow before hanging up. The APCM flashes the line, the user is connected to the voice call, and the DPCM is on hold. When coming back, another flash hook connects the APCM and DPCM, at which time they renegotiate the connection using quick connect.
Case 2
When a MOH request is denied. The two modems negotiate, and the server denies the hold; then the two modems reconnect. This is the call-waiting survival mode.
Modem-on-Hold/Call-Waiting Survival Implications and User Model
This model provides the broadband-like service of data and voice service on the same line. The service does not allow for simultaneous voice and data, as broadband does. However, it does allow a single phone line to serve as voice and data; the data call is returned without resetting the user’s context. Additionally, the model allows ISPs and OSPs to determine the maximum amount of on-hold time. ISPs and OSPs can potentially charge for this service, and provide a level of service (number of minutes on hold) based on the assessed amount.
Many households use the same phone line for both voice calls and data (Internet), so when the user is browsing the Internet, an incoming call cannot get through. MOH allows you to receive an incoming call and stay connected to the Internet (Call-Waiting service from your phone company is all that is required). It also works in reverse; you can initiate a voice call while connected and keep the modem connection.
Your ISP defines the “hold” time. The V.92 specification allows for hold times to be anywhere from 10 seconds to infinite. When you hang up the phone you can resume browsing. Initiating calls is easy with MOH. First, a MOH application is executed. This program suspends the data connection between your modem and the ISP so you can pick up your phone and make an outgoing call in the usual way. The application puts the modem "on-hold", flashes the hook, and a dial tone appears on the extension handset so you can make a call. When your call is complete, the modem will detect an extension on hook, flash the hook twice, and return to the data (Internet) connection.
There are different types of CallerID available from the telephone companies. These services may be called by a different name in other countries. First and foremost, you must have Call Waiting in order to take advantage of MOH. CallerID (CID) is not required. There are 2 types of CID, type 1 and type 2.
Type 1 CID is a service that allows a telephone subscriber to receive information on the incoming call BEFORE the user (or modem) takes the call by going off-hook. Sometimes called on-hook CID, it does not require Call Waiting, but it does require hardware support on the modem board if you want to use this feature via the modem. This is because without specific hardware support, there is no data path from the telephone line to our modem device when the modem is in the on-hook condition.
Type 2 CID (also referred to as CID on Call Waiting) does not require hardware support on the modem board. Type 2 CID is not required for MOH to work. However without type 2 CID support from the Telco, the user will not be able to receive details (telephone number) of the incoming third-party call. For the purposes of a MOH discussion, we will only refer to Type 2 CID.
For MOH functionality, the user must have Call Waiting service from their telephone company at a minimum. Optionally, for CID on CW, the user must have CID on Call Waiting (not just CID) service from the Telco. Most international Telcos support Call Waiting, however it is up to the modem to support the various CW tones in the driver. Please check with your modem manufacturer. Not every international Telco offers CID on Call Waiting as a commercial package, even if it is supported in the Telco equipment. First, check with your telephone company to see if Call Waiting CID is offered as a service. Second, check with your modem manufacturer for a list of countries supported.
Most modem manufacturers will supply a MOH applet with the modem driver. Check with your modem manufacturer for details.
PCM Upstream has been discussed in the standards bodies for several years. To provide overall industry-wide support, it has been combined with quick connect and Modem-On-Hold™ (MOH) to provide an acceptable solution to all involved parties. PCM Upstream operates in a topology similar to that of V.90, where there must be only one analog loop, between the APCM and the central office.
Unlike quick connect and MOH, PCM Upstream does not fundamentally change the modem’s user model. It does provide some extra utility for services that require more symmetric data flow.
PCM Upstream boosts the upstream data rates between the user and ISP to reduce upload times for large files and email attachments. A maximum of 48 Kbps upstream rates is supported. PCM Upstream will work particularly well with new equipment such as Internet-connected digital cameras, which primarily upload rather than download information.
What is V.44 data-compression?
V.44 is a new data-compression protocol that delivers data rates 10 percent through 120 percent faster than those achieved by the existing V.42bis compression protocol.
The most popular activity on the Internet is browsing, and this is where V.44 delivers the greatest improvement over V.42bis, so users can enjoy speeds up to 120 percent faster than with the older protocol. Popular sites such as Amazon.com and eBay use highly compressible HTML files, so online shopping is faster than ever. V.44 also increases data throughput for email (by 27 percent), Word documents (by 21 percent), Power Point files (by 10 percent), and C source files (by 45 percent).
Client and server modem software require an update to support V.44, compliance with this standard will vary by region and service provider.
V.44 Background
Voice band modem technology provides the most ubiquitous data communication method on earth. But this ubiquity has its limitations. Because of the severely limited bandwidth and the widely varying quality of this bandwidth, data rates are slow relative to broadband channels. As a result, every byte sent across the channel is precious.
Early in the development of modem data technologies, it was recognized that one of the best ways to optimize the amount of data transferred across this narrow channel was to compress the data immediately before sending it and having a matching decompression on the other side of the link. A number of data compression standards were developed over the years. The V.42bis standard became the method most widely used.
In order to make the compression techniques as widespread as possible, the compression engine is pushed as low in the OSI stack as possible, to just above the link layer. In this way, all kinds of applications benefit from the compression without having to worry about implementing it separately in every application for different operating systems on different platforms. This pushed the V.42bis compression algorithm to be implemented directly on the modem itself, rather than on the host processor.
As a result, compression algorithms need to have the following characteristics:
- Low processing load—the processors used to control modems are low complexity microcontrollers
- Low memory requirements—to bound the cost of modems, the memory sizes are kept small
- Low latency requirements—to make sure that applications such as gaming and telephony are possible, the amount of time to go through the encoder and the decoder on the other side must be very small. V.42bis became and is a widespread standard in the voice band modem area
Hughes Network System encountered a similar problem with precious bandwidth when it implemented its VSAT and DirecPC products. Hughes implemented a compression algorithm that has many of the same constraints as voice band modems. This algorithm is ideal for packet networks and has been deployed and executed worldwide in HNS satellite networks. Late in 1999, Hughes offered its compression algorithm as an alternative to V.42bis in public communications standards bodies. This algorithm was reviewed by the American and International communication standards bodies, and adopted as a new compression standard called V.44.
Choosing Files to Compare
Choosing files to compare two algorithms always creates acrimony. There are contrived files that show off one algorithm over another. However, most modems today are used to access the Internet. The most meaningful files to compare performance of two algorithms are those typical of Internet usage.
Files examined here are considered typical of an Internet session, some contrived files, and ones based on files create by standards testing bodies:
- Webfile: a file consisting of the captured downstream data from a web browsing session created by ADI – This stream went into map.com, so there are lots of images
- Websurf: a file consisting of the captured downstream data from a web browsing session created by HNS. Browsing was mostly cnn.com, yahoo, etc. Intended to capture a typical Internet browsing session
- Amazon.ts6: eight web pages from Amazon.com searches merged together with 20 K of random images data between each page
- Mail.txt: A electronic mail file was created consisting of the following:
- Jokes received from a friend (pretty bad ones at that). All subjects, typically about 2,000 to 4,000 bytes each
- TR30.1 meeting notices and some mail
- Mail with attachments:
- LZJH C code
- LZJH Study Group 16 contribution Word document
- RTF Document
- Other Word documents
- Big1.tst, Big2.tst, Big3.tst: created by replicating the TSB38 standard test file BIG1, BIG3 and BIG5 respectively many times
- Ebay.ts1: several web pages from eBay.com while searching for sports collectibles
- Cdsearch.tst: results of an artist search from an online CD music store
- Maxlen.tst: 255 A's, then 255 B's, etc. to test string extensions. All possible 8-bit characters are duplicated 255 times. This file is a contrived file that stresses the compression algorithms.
These files were developed to emulate the type of data transferred over the Internet in a typical session, and to include some files used in standardized testing of communications systems.
How Does V.44 Stack Up?
Table 1-1lists the results of running the files mentioned above through three different compression algorithms: V.44, V.42bis, and WinZip.
What Does This Mean for Me?
In Figure 1, V.42bis is normalized to 1. The graph illustrates that V.44 has 12 to 230 percent better compression ratios than V.42bis on the same files. This means that a V.92 modem with V.44 included would effectively run 12 to 230 percent faster than one with V.42bis. This improvement is significant, and similar to the improvement seen when going from V.34 modems to V.90 modems.
Can’t We Do Better Than That?
But this graph also shows that WinZip has much higher compression ratios. Why not just use the WinZip algorithm and be that much better? Remember the limitations stated in the introduction: Limited processing horsepower, limited memory, low latency. Because the WinZip algorithm runs on the PC, it has access to a very powerful processor and a lot of memory. It can look at very large chunks of data because of all of that memory. Also, because WinZip essentially is a batch process, and not done in real time, there are no latency requirements. It can take a long time looking for similarities and compressing optimally. In addition, the WinZip and other similar algorithms do a two-pass compression. This is not possible with streaming data, because the modem compression algorithms never see the entire file – only pieces as it streams past. So V.44 shows a very good improvement over V.42bis while having similar processing, memory and latency performance. The compression ratios found in PC standard compression programs cannot be reached with streaming data.
What Does This Mean for Me?
Let’s assume that V.44 delivers a 26% improvement in compression rates over the existing V.42bis compression method. If you were connecting with a V.90 modem at 44 Kbps with V.44, your effective data rate would be the same as if you could connect with that same modem at 56 K. If you were connecting at 28.8 K with V.42b, with V.44, you would have the equivalent performance of 36 Kbps. Clearly, V.44 provides a next level of performance for voice band modems.
NetWaiting™
NetWaiting (a BVRP application) is bundled with the Conexant V.92 modem chipset and driver. In NetWaiting's initial release, Call Waiting is supported for the US, Japan, China, Israel, France, Italy and Singapore. Call Waiting CID is supported for US, Japan, Israel, France and Italy. More countries will be added over time.
NetWaiting, like all MOH applications, requires the user to have Call Waiting service with their telephone company. Additionally, Call Waiting must be enabled. Some ISPs (e.g. AOL) automatically turn off Call Waiting in their dial up scripts.
For customer convenience, Conexant bundles a Modem-on-Hold™ application called NetWaiting. The NetWaiting applet supports the following features:
- Intercept MOH events triggered by the modem drivers, through the API supplied by the modem manufacturer
- If calls are screened, prompt user for a decision when an incoming call shows up, (with display of the Caller-ID or friendly name, if present): Accept call and put modem on hold, or reject call and continue Internet session. If the session is not a V.92 session, then accepting the call will automatically terminate the Internet session
- Display of the remaining time before making a decision on the incoming call (V.92 only)
- Display the on-hold remaining time allotted by the ISP and let the user either disconnect the Internet connection or hang up the call and resume the Internet session
- Allow the user to place outgoing calls by putting the modem on hold if an Internet connection is engaged
- Allow the user to configure the behavior of the applet through a “Preferences” menu:
· Enable/disable MOH (immediate action)
· Specify per call options: Ignore all incoming calls, Accept all incoming calls and disconnect Internet connection, Screen all incoming calls and prompt the user (active at the next Internet session)
· Ability to edit a friendly name table to display Caller-Ids in a meaningful way for the user (immediate action)
Created On: 3/20/2005 8:04:00 AM
Last Modified On: 3/13/2011 8:58:00 PM
Article ID: 10763
Viewed 5,032 times
|
|