Home | Skip to Content | Skip to Search | Skip to Navigation | Skip to Footer |
Worldwide [change] |Register |About Cisco
Guest

Hierarchical Navigation

Asynchronous Connections

What is the Difference Between Async and LAP-M Framing?

Downloads

Document ID: 14965


Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Advantages of EC Protocols over Async Framing
Negotiating Error Correction
Using Async Framing
Related Information

Introduction

Asynchronous framing, also known as "normal mode", typically transmits each character across the modem link in a ten-bit async frame, consisting of one start bit, one stop bit, and eight databits (or seven databits with one parity bit). When you do not employ Error Correction (EC), modems use asynchronous framing over the Public Switched Telephone Network (PSTN) link.

Link Access Protocol-Modem (LAP-M) and Microcom Network Protocol 4 (MNP4) are EC protocols used on modem links. EC protocols put the payload into frames, employ Cyclic Redundancy Checks (CRCs), and perform retransmission. EC is required for data compression, such as V.42bis, on the link.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Advantages of EC Protocols over Async Framing

  • Async framing has a fixed 20 percent overhead per each individual character (two overhead framing bits per eight bits of payload), while EC protocols use frames of variable length. The bigger the payload of the frame, the less the relative share of the overhead. For example, LAP-M usually adds only about five percent framing overhead.

  • EC protocols employ error detection and retransmission, whereas async framing delegates this function to the higher layer protocols (typically error detection is performed then by PPP layer and retransmission is done by TCP). Besides, the optional selective reject (SREJ) functionality of LAP-M (implemented in NextPort modems via CSCdx03968) allows EC protocols to resend only the corrupted frames, while TCP has to retransmit a complete IP packet, which may be much bigger. This typically means that recovery from an error is much faster with EC protocols (on the order of 100ms) than in the async (TCP over PPP) case (on the order of two seconds). Hence, the EC protocols can maintain a much better effective throughput in the presence of bit errors.

  • Link-layer data compression (such as V.42bis, MNP5 or V.44) requires an EC protocol. If the payload is compressible enough, the effective throughput on the EC-enabled link can exceed the physical data rate of the line.

Negotiating Error Correction

The EC layer (LAP-M or MNP4) is negotiated after the modems have fully trained up in a modulation (such as V.34 or V.90) and so are theoretically capable of getting data across the link, even if it has errors. The V.42 recommendation specifies ODP and ADP sequences sent by the originating and answering modems in order to choose the EC protocol: LAP-M is the preferred method and MNP4 is the alternative. Async framing is isually the option of last resort. Once negotiated, the EC protocol or the asynchronous framing mode remains unchanged as long as the connection stayes up.

Modems typically have a window of time to negotiate an EC protocol - for example, ten seconds on MICA (S16 and S17) or NextPort (S16 and S17). If EC negotiation does not succeed within this window, then the modems fall back to async framing. The following sorts of conditions might cause this fallback:

  • EC is disabled on the peer modem.

  • The answer modem receives the protocol negotiation fallback character. This character is by default a Carriage Return - CR (ASCII character #13, hexadecimal value 0x0D).

  • Data path (modulation) delivers heavily-errored bits in one or both directions, so that no EC protocol can be negotiated.

  • The modem link retrains soon after the initial modem trains up, before the EC negotiation is complete. The delay caused by the retrain makes the EC negotiation window timer to expire.

The latter two cases are indicative of a poor modem transmission. This is often caused by a bad circuit, or an overly optimistic modulation selected relative to the circuit quality. If you observe a large number of async framed connections, this may be indicative of transmission problems. It may be helpful to reduce the DCE (modem) rate in such cases. You can adjust the S-registers, S15 through S18 and S22 through S25 to define the EC for the modems. Refer to the AT Command Set and Register Summary for MICA or NextPort AT Commands and S Registers Reference for more information on S-registers.

Using Async Framing

In some situations, it may be advantageous to use async framing rather LAP-M or MNP4, such as with Point of Sale (PoS) applications like credit-card readers. PoS applications need to move very small amounts of data as quickly as possible. For this situation, let us assume that we are transferring 500 bytes. With such limited amounts of data to be transferred, PoS systems need not waste time training up at a high speed modulations, like V.90, and negotiate EC, since this could take up to 30 seconds. Rather, they train up using a low speed modulation standard such as Bell212 at 1200 bps. At 1200 bps, the circuit can move 500 bytes in less than four seconds. So, if the modems train in Bell212 in three seconds, skip EC negotiation, transfer all the data in four seconds, then the whole transaction will be complete in under ten seconds:

Feb 25 10:17:33.847: ISDN Se0:15: RX <-  SETUP pd = 8  
callref = 0x006C
Feb 25 10:17:33.847:         Sending Complete
Feb 25 10:17:33.847:         Bearer Capability i = 0x9090A3
Feb 25 10:17:33.847:         Channel ID i = 0xA18381
Feb 25 10:17:33.847:         Progress Ind i = 0x8483 
- Origination address is non-ISDN
Feb 25 10:17:33.851: VDEV_ALLOCATE: 1/0 is allocated
Feb 25 10:17:33.851: EVENT_FROM_ISDN: dchan_idb=0x6290AB1C, 
call_id=0xB, ces=0x1   bchan=0x0, event=0x1, cause=0x0
Feb 25 10:17:33.851:  dev in call to isdn : set dnis_collected & fap_notify
Feb 25 10:17:33.851: EVENT_FROM_ISDN:(000B): DEV_INCALL at slot 1 and port 0
Feb 25 10:17:33.851: EVENT_FROM_ISDN: decode:calling oct3 0x21, 
called oct3 0x81, oct3a 0x83,mask 0x3F
_info:calling oct3 0x21, called oct3 0x81, oct3a 0x83,mask 0x3F
Feb 25 10:17:33.855: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 0
Feb 25 10:17:33.855: Mica Modem(1/0): Configure(0x1 = 0x0)
Feb 25 10:17:33.855: Mica Modem(1/0): Configure(0x23 = 0x0)
Feb 25 10:17:33.855: Mica Modem(1/0): Call Setup
Feb 25 10:17:33.855: csm_connect_pri_vdev: TS allocated at bp_stream 0, 
bp_Ch 10, vdev_common 0x61E8EF70 1/0
Feb 25 10:17:33.855: ISDN Se0:15: TX ->  CALL_PROC pd = 8  callref = 0x806C
Feb 25 10:17:33.855:         Channel ID i = 0xA18381
Feb 25 10:17:33.855: ISDN Se0:15: TX ->  ALERTING pd = 8  callref = 0x806C
Feb 25 10:17:33.903: Mica Modem(1/0): State Transition to Call Setup
Feb 25 10:17:33.903: Mica Modem(1/0): Went offhook
Feb 25 10:17:33.903: CSM_PROC_IC2_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, 
port 0
Feb 25 10:17:33.903: ISDN Se0:15: TX ->  CONNECT pd = 8  callref = 0x806C
Feb 25 10:17:33.959: ISDN Se0:15: RX <-  CONNECT_ACK pd = 8  callref = 0x006C
Feb 25 10:17:33.963: ISDN Se0:15: CALL_PROGRESS: CALL_CONNECTED call id 0xB, 
bchan 0, dsl 0
Feb 25 10:17:33.963: EVENT_FROM_ISDN: dchan_idb=0x6290AB1C, call_id=0xB, 
ces=0x1 bchan=0x0, event=0x4, cause=0x0
Feb 25 10:17:33.963: EVENT_FROM_ISDN:(000B): DEV_CONNECTED at slot 1 and port 0
Feb 25 10:17:33.963: CSM_PROC_IC6_WAIT_FOR_CONNECT: 
CSM_EVENT_ISDN_CONNECTED at slot 1, port 0
Feb 25 10:17:33.963: Mica Modem(1/0): Link Initiate
Feb 25 10:17:34.007: Mica Modem(1/0): State Transition to Connect
Feb 25 10:17:34.399: Mica Modem(1/0): State Transition to Link
Feb 25 10:17:37.159: Mica Modem(1/0): State Transition to Trainup
Feb 25 10:17:38.183: Mica Modem(1/0): State Transition to EC Negotiating
Feb 25 10:17:38.199: Mica Modem(1/0): State Transition to Steady State

Using an extra three seconds to negotiate EC would be a waste for this situation. Also keep in mind that low bit rate modulations normally have a very low bit error rate, so EC is practically unneccessary.

Related Information

Updated: Nov 15, 2007 Document ID: 14965