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

Hierarchical Navigation

Asynchronous Connections

Troubleshoot V.110 Connections on Cisco Access Servers

Downloads

Document ID: 24675


Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Background Information
Benefits
Troubleshoot
      Troubleshooting Guidelines
      Bearer Capability in a V.110 Call
      How the User Rate is Calculated
debug Commands
NetPro Discussion Forums - Featured Conversations
Related Information

Introduction

This document provides information you can use to troubleshoot basic V.110 issues.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

V.110 is supported on these software and hardware versions:

  • Cisco AS5xxx platforms in Cisco IOS® Software Release 12.0(5T) and above.

  • Cisco 3600 platforms in Cisco IOS Software Release 12.1(5)T and above.

Conventions

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

Background Information

  • V.110 is a real-time method of encapsulating varying data rates and the associated RS-232 signals into a 64-Kbps ISDN B-channel.

  • You can use this procedure to transparently rate-adapt asynchronous and synchronous data rates from 600 bps to 38.4 Kpbs over a single 64-Kbps channel.

  • V.110 is used to transport data over Global System for Communications (GSM)-type mobile phones.

  • V.110 over ISDN support is being added to the Machine Access Restrictions (MARs) platform to support digital modems in many countries which use E1 with ISDN.

  • V.110 is a method of ISDN rate adaptation, as an alternative to V.120. It provides DTEs with V-series type interfaces with access to ISDN networks by "bit stuffing". Many V.110 devices are used in Europe and Japan.

  • The only Cisco equipment that implements V.110 is digital internal modems (and only for ISDN connections). However, since there are data terminal equipment (DTE) ports on Cisco equipment, you can use a third party terminal adapter (TA) to terminate a V.110 call externally.

    Note: You can implement V.110 using external TAs by using a Basic Rate Interface (BRI) attached to an async port. This is outside the scope of this document.

  • Analogue internal modems can also terminate analog calls, but not digital rate adaptations. For more information, refer to Configuring and Managing Integrated Modems – Table 5.

Benefits

The V.110 recommendation of the ITU-T rate adapts a low-speed connection to an ISDN B-channel, allowing the remote station or terminal adapter to use the fast call-setup times offered by ISDN. This characteristic is often used for GSM wireless data connectivity. Since most modular switch controllers (MSCs) and interworking functions (IWFs) are attached to digital trunks, this is preferable to using modem transport.

Troubleshoot

The sections below provide some suggestions to help you troubleshoot V.110 problems.

Troubleshooting Guidelines

If you cannot establish a V.110 call, try to answer these questions:

Can you terminate analog calls in the router?

V.110 calls do not require any specific configuration in the router (unlike V.120 calls). Therefore:

  • If you can terminate analog calls in the router, you could normally expect to terminate the V.110 calls as well. (The only exception is the Cisco AS5200 which has a modem card and a separate V.110 card. However, this product is now End of Life [EoL].)

  • If you cannot terminate analog calls, refer to the Troubleshooting Modems document.

Is this an incoming or an outgoing V.110 call?

  • Incoming calls:

    • Check whether the call terminates in a Basic Rate Interface (BRI) or Primary Rate Interface (PRI) since these are handled differently.

      Note: Be aware that ISDN parses V.110 parameters in the bearer capability (BC) Information Element (IE) for PRI, but it does not parse them for BRI. For BRI, ISDN only supports V.110 parameters in low layer compatibility (LLC).

    • Check Cisco Bug ID CSCdw75802. This was integrated in Cisco IOS Software Release12.2(08.05)T.012.002(008.005). In an incoming V.110 call there are two possibilities:

      • BC should be 8890 and you must point the LLC subfield to the V.110 sub rate.

      • BC should be pointing to the V.110 sub rate.

      More information on decoding BC and LLC is available at the cosi-nms.sourceforge.net leavingcisco.com web site.

    • In incoming calls, if the BC and LLC are not the same, and if both specify V.110, the LLC overwrites the BC.

      For example, in an incoming V.110 call, BC = 0x8890214846BB but LLC=0x8890214840BB.

      In this example, the flow control is different between the BC (46) and the LLC (40).

      Here is some sample debug isdn Q931 output showing V.110 and non-V.110 calls. Check the BC and LLC field to see if the call is a V.110 call. The output shows that this is not a V.110 call because the BC shows a data call and there is no LLC field.

      *Mar  3 00:08:58.400: ISDN BR2/0: RX <- SETUP pd = 8  callref = 0x11
*Mar  3 00:08:58.400:         Sending Complete
*Mar  3 00:08:58.400:         Bearer Capability i = 0x8890
*Mar  3 00:08:58.404:         Channel ID i = 0x89
*Mar  3 00:08:58.404:         Calling Party Number i 
 = 0x21, 0x81,'709660723', Plan:ISDN, Type:National
*Mar  3 00:08:58.404:         Called Party Number i 
 = 0x81, '013363045',Plan:ISDN, Type:Unknown
*Mar  3 00:08:58.408: CCBRI_Go Fr L3 pkt (Len=37) :

      This a V.110 call. The BC shows a data call. However, there are V.110 parameters in the LLC IE.

      Sectra3#
*Mar  3 00:26:18.015: ISDN BR2/0: RX <- SETUP pd = 8  callref = 0x05
*Mar  3 00:26:18.015:         Sending Complete
*Mar  3 00:26:18.015:         Bearer Capability i = 0x8890
*Mar  3 00:26:18.015:         Channel ID i = 0x89
*Mar  3 00:26:18.019:         Calling Party Number i
 = 0x21, 0x81,'708241028', Plan:ISDN, Type:National
*Mar  3 00:26:18.019:         Called Party Number i
 = 0x81, '013363045',Plan:ISDN, Type:Unknown
*Mar  3 00:26:18.019:        Low Layer Compat i = 0x8890214B60BB

      This a V.110 call. The BC shows the V.110 call.

      *Mar  3 00:13:45.384: ISDN BR2/0: RX <- SETUP pd = 8  callref = 0x0B
*Mar  3 00:13:45.384:         Sending Complete
*Mar  3 00:13:45.388:         Bearer Capability i
 = 0x8890214846BB
*Mar  3 00:13:45.388:         Channel ID i = 0x89
*Mar  3 00:13:45.388:         Calling Party Number i
 = 0x21, 0x83,'702286921', Plan:ISDN, Type:National
*Mar  3 00:13:45.388:         Called Party Number i
 = 0x81, '013363045',Plan:ISDN, Type:Unknown

  • Outgoing calls:

    In this example, we receive a disconnect from the Telco side:

    Router#

!--- Reverse telnet to mica modem

AT
OK
atz
OK
ats29=8
OK
atdi002103588962 7
*Mar  1 18:23:03.167: Modem 2/0 Mica: configured for Originate mode,
with Null signaling, 0x1 tone detection.
*Mar  1 18:23:03.171: Modem 2/0 Mica: received dialstring I002103588967
*Mar  1 18:23:03.171: ISDN BR3/1: TX -> SETUP pd = 8  callref = 0x03
*Mar  1 18:23:03.175:         Bearer Capability i = 0x88902148463B
*Mar  1 18:23:03.175:         Channel ID i = 0x83
*Mar  1 18:23:03.175:         Called Party Number i = 0x80,'002103588967', 
Plan:Unknown, Type:Unknown
*Mar  1 18:23:03.175:         Low Layer Compat i = 0x8890214846BB
*Mar  1 18:23:03.179:         Sending Complete
*Mar  1 18:23:03.263: ISDN BR3/1: RX <- CALL_PROC pd = 8  callref = 0x83

*Mar  1 18:23:03.263:         Channel ID i = 0x8A
*Mar  1 18:23:03.299: Modem 2/0 Mica: in modem state CALL_SETUP
*Mar  1 18:23:07.231: ISDN BR3/1: RX <- DISCONNECT pd = 8  callref =0x83

    One possible solution is to configure isdn send-complete. However, the switch might encounter problems with the BC. For more information, check Cisco Bug ID CSCdx56539 in Cisco IOS Software Release 12.2.11.1 and later.

For more information refer to the ITU specification, Q series, Q931 - Figure 4-11: "Q.931 Bearer capability information element" and Table 4-6: "Q.931 Bearer capability information element".

Bearer Capability in a V.110 Call

In this example, a bad call enables the V.110 call to complete (modem steady state). However, the data path appears to be garbage. None of the LLC octets are set up, since these are missing from the bearer capability (BC).

V.110 Rates - Octet 5a
-----------
600   0x01
1200  0x02
2400  0x03
4800  0x05
7200  0x06
9600  0x08
14400 0x09
19200 0x0b
28800 0x13
38400 0x0d

Intermediate Rate - Octet 5b
-----------------
8K  - 0x1
16K - 0x2
32K - 0x3
64K - 0x4


5a User Rate
5b Intermediate Rate
5b NIC on Tx/Rx
5b Flow Control on Tx/Rx
5c # of Databits
5c # of Stopbits
5c Parity

BC  - 0x8890214840BB
LLC - 0x8890214846BB

llc valid, speed 64, call type is V.110
speed:8 async:Y rate 2 nic(tx:N rx:N) fc(tx:N rx:N) stop 1 data 3 parity 3

*Jan 15 19:37:49.402: Mica Modem(1/45): Configure(0x13 = 0x8)
*Jan 15 19:37:49.402: Mica Modem(1/45): Configure(0x3A = 0x8)
*Jan 15 19:37:49.402: Mica Modem(1/45): Configure(0x2 = 0x3)
*Jan 15 19:37:49.406: Mica Modem(1/45): Configure(0x4 = 0x1)
*Jan 15 19:37:49.406: Mica Modem(1/45): Configure(0x3 = 0x3)
*Jan 15 19:37:49.406: Mica Modem(1/45): Configure(0x3B = 0x0)
*Jan 15 19:37:49.406: Mica Modem(1/45): Configure(0x1 = 0x0)
*Jan 15 19:37:49.406: Mica Modem(1/45): Configure(0x23 = 0x0)
*Jan 15 19:37:49.406: Mica Modem(1/45): Call Setup

Broken down into bits, the LLC looks like this:

88
10001000        ITU Standardized coding
                Unrestricted digital information

90
10010000        Circuit Mode
                64 kbit/s

21
00100001        Layer 1 Ident.
                ITU Standardized rate adaptation V.110

48
01001000        Async
                In-band negotiation not possible
                9.6 kbit/s

46
01000110        16 kbit/s Intermediate Rate
                Not required to send data with network independent clock

                Cannot accept data with network independent clock
                Required to send data with flow control mechanism
                Can accept data with flow control mechanism
                (bit 1 is spare - 0 )
BB
10111011        Number of stop bits ( 01 = 1 bit)
                Number of data bits (11 = 8 bits)
                Parity information (011 = None)

The only difference is between 46 and 40. These two bits are used for Tx and Rx flow control. A value of 40 means that the client is telling us not to use it.

How the User Rate is Calculated

Intermediate rates of 8k, 16k, 32k, and 64k represent 1, 2, 4, or 8 bits (respectively) of V.110 frame data that have been put into each byte over the 64k channel.

V.110 frames (made up of 10 bytes excluding the intermediate rate padding) can contain 6, 12, 24, 30, 36, or 48 bits of actually user data (the adaptation).

You can derive the various rates as follows:

       9600 bps = 64k * (2/8) * (48/80)
                          ^        ^
                          |        |
16k IR - 2 bits per byte -'        |
                                   |
48 bits of the 80 bit V.110 frame -'

You can "sniff" out the user rate in the B channel (if you know it is a V.110 call) since you know that the first byte of a V.110 frame is all zeros. The first byte of each V.110 frame looks like this:

For 64k IR:  For 32k IR:  For 16k IR:  For 8k IR:
00000000     00001111     00111111     01111111
             00001111     00111111     01111111
                          00111111     01111111
                          00111111     01111111
                                       01111111
                                       01111111
                                       01111111
                                       01111111

Once you know the IR and the first byte of the V.110 frame, you can jump down to the 5th byte and look at E1, E2, and E3 bits. This tells you which adaptation (again 6, 12, 24, 30, 36, or 48 bits) to use.

         E1  E2  E3
 6 bits   1   0   0
12 bits   0   1   0
24 bits   1   1   0
30 bits   0   0   1
36 bits   1   0   1
48 bits   0   1   1

debug Commands

Collect output from the following debug commands:

  • configure terminal

  • service timestamps debug datetime msec

  • service timestamps log datetime msec

  • exit

  • debug isdn q931

  • debug modem csm

  • debug ppp negotiation

  • term mon

Note: Before V.110 can start data exchange, it performs some signaling and negotiation. It takes around 500 ms to complete this phase. MICA has an S54 bit to enable blind connection for V.110 calls. It is designed for clients who fail to raise S and X bits and therefore do not conform to V.110.

Note: The Cisco V.110 implementation (neither MICA nor Nextport) does not support In-band Parameter Exchange (IPE). For more information, refer to the ITU V.110, Appendix I.

NetPro Discussion Forums - Featured Conversations

Networking Professionals Connection is a forum for networking professionals to share questions, suggestions, and information about networking solutions, products, and technologies. The featured links are some of the most recent conversations available in this technology.
NetPro Discussion Forums - Featured Conversations for Access
Network Infrastructure: Remote Access

Related Information

Updated: Dec 12, 2005Document ID: 24675