OpenSS7
SS7 for the
Common Man
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.
Last modified: Thu, 18 Dec 2008 06:35:36 GMT
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> SIGTRAN -> draft-rao-sigtran-v5ua-01
Quick Links

Download

SCTP

SIGTRAN

SS7

Hardware

STREAMS

Asterisk

Related

Package

Manual

FAQ

SIGTRAN

SCTP

UA

TUA

SUA

ISUA

M3UA

M2UA

M2PA

IUA

TALI

SS7 over IP

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

draft-rao-sigtran-v5ua-01

Description: Request For Comments

You can download source copies of the file as follows:

draft-rao-sigtran-v5ua-01.txt in text format.

Listed below is the contents of file draft-rao-sigtran-v5ua-01.txt.



Internet Engineering Task Force                              Sanjay Rao
                                                    Neeraj Khanchandani
                                                         Fahir Ergincan
                                                           Eva Weilandt
                                                            Anil Vydyam
                                                       Ranjith Mukundan
                                                 Narsimuloo Mangalpally
Internet Draft                                          Nortel Networks

Expires in 6 months                                       November 2000

          V5.2 and DPNSS/DASS 2 extensions to the IUA protocol
                <draft-rao-sigtran-v5ua-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

1. Abstract

   This document defines a mechanism for backhauling of V5.2, DPNSS and
   DASS 2 messages over IP by extending the ISDN User Adaptation Layer
   Protocol (<draft-ietf-sigtran-iua-09.txt>). The document aims to
   become an Appendix to IUA and to be the base for V5.2 and DUA
   (DPNSS/DASS 2 User Adaptation layer) implementation.

Table of Contents

   1.0  Introduction ......................................... 2
   2.0  V5UA ................................................. 2

Rao, Khanchandani, Ergincan, Weilandt,                         [page 1]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

   2.1.1  Scope .............................................. 2
   2.1.2  Terminology ........................................ 3
   2.1.3  V5.2 Overview ...................................... 4
   2.1.4  Addition to boundary primitives .................... 6
   2.1.4.1  V5 specific boundary primitives .................. 6
   2.2.0  Proposed V5.2 Backhaul Architecture ................ 7
   2.2.1  IUA Message Header for V5.2 ........................ 8
   2.2.2  V5 Additions to IUA Boundaries ..................... 9
   2.2.3  V5 Layer 1 Failure Message ......................... 9
   3.0  DUA .................................................. 9
   3.1.1  Scope .............................................. 10
   3.1.2  Terminology ........................................ 10
   3.1.3  DPNSS Overview ..................................... 10
   3.1.4  Proposed DPNSS Backhaul Architecture ............... 10
   3.2.0  Changes from IUA ................................... 11
   3.2.1  Message Header ..................................... 12
   3.2.2  Adaptation Layer Identifier ........................ 13
   3.2.3  Unit Data Message .................................. 13
   3.2.4  Status Message ..................................... 13
   3.2.5  Error Message ...................................... 14
   3.3.0  IANA Considerations ................................ 14
   3.4.0  Message Sequence in DUA ............................ 15
   3.4.1  Resetting of single DLC ............................ 15
   3.4.2  Resetting all DLCs in a link ....................... 15
   3.4.3  Information Transfer on a DLC ...................... 15
   3.4.4  Link Takedown(Single DLC) .......................... 16
   3.4.5  Link Takedown(All DLCs) ............................ 16
   3.4.6  Getting link Status ................................ 16
   3.4.7  Error conditions ................................... 16
   3.4.8  Glossary of Terms .................................. 16
   4.0  References ........................................... 17
   5.0  Author's Addresses ................................... 17
   5.1  V5UA Authors ......................................... 17
   5.2  DUA Authors .......................................... 18

1.0  Introduction

   This document describes a method of implementing V5.2 & DPNSS/DASS2
   backhaul messaging over IP using a modified version of the ISDN
   User Adaptation Protocol (IUAP). This document aims to
   become an Appendix to IUA and to be the base for the "appli-
   cation guide".

2.0  V5UA

2.1.1  Scope

Rao, Khanchandani, Ergincan, Weilandt,                         [page 2]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

   There is a need for a V5.2 backhaul to meet the following
   access types:

        - Analog telephone access

        - ISDN Basic rate access

        - ISDN Primary Rate access (V5.2)

        - Other analog or digital accesses for semi-permanent
          connections without associated outband signaling
          information.

2.1.2  Terminology

   Bearer Channel Connection (BCC) protocol - A protocol which
        allows the LE to instruct the AN to allocate bearer
        channels, either singly or in multiples, on demand.

   Communication channel (C-channel) - A 64 kbit/s time slot on
        a V5.2 interface provisioned to carry communication
        paths.

   Communication path (C-path) - Any one of the following
        information types:

        - The layer 2 data link carrying the Control protocol

        - The layer 2 data link carrying the Link Control protocol

        - The layer 2 data link carrying the PSTN signaling

        - Each of the layer 2 data links carrying the protection
          protocol

        - The layer 2 data link carrying the BCC protocol

        - All the ISDN Ds-type data from one or more user ports

        - All the ISDN p-type data from one or more user ports

        - All the ISDN t-type data from one or more user ports

        Note: This definition includes the possibility that
        there is more than one C-path of the same information

Rao, Khanchandani, Ergincan, Weilandt,                         [page 3]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

        type, each allocated to a different logical C-channel.

   Logical Communication channel (Logical C-channel) - A group
        of one or more C-paths, all of different types, but
        excluding the C-path for the protection protocol.

   Multi-link - A collection of more than one 2.048 kbit/s link
        which together make up a V5.2 interface.

   Multi-Slot - A group of more than one 64kbit/s channels pro-
        viding 8Khz and time slot sequence integrity, generally
        used together within an ISDN Primary Rate Access
        (ISDN-PRA) user port, in order to supply a higher bit-
        rate service.

   Physical Communication Channel (Physical C-channel) - A
        64kbit/s time slot on a V5.2 interface which has been
        assigned for carrying logical C-channels. A physical
        C-channel may not be used for carrying bearer channels.

   Primary Link - A 2.048 kbit/s link in a multi-link V5.2
        interface whose physical C-channel in time slot 16 carries a C-
        path for the protection protocol and, on V5.2
        initialization, also the C-path for the control protocol, link
        control protocol, and the BCC protocol. Other
        C-paths may also be carried in the time slot 16.

   Secondary Link  - A 2.048 kbit/s link in a multi-link V5.2
        interface whose time slot 16 carries a C-path for the
        protection protocol, and, on V5.2 initialization, acts
        as the standby C-channel for the control protocol, link
        control protocol, and BCC protocol and any other C-
        paths initially carried in time slot 16 of the primary
        link.

2.1.3  V5.2 Overview

   V5.2 is an industry standard ETSI interface (reference ETS
   300 347-1) defined between a Local Exchange (LE) and an Access
   Network (AN) providing access to the following types:

Rao, Khanchandani, Ergincan, Weilandt,                         [page 4]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

        - Analog telephone access

        - ISDN Basic rate access

        - ISDN Primary Rate access (V5.2)

        - Other analog or digital accesses for semi-permanent
          connections without associated outband signaling
          information

        The original V5 specification uses 2048 kbps links,
        V5.2 may use upto 16 such interface links.

                ----------              ----------        o--o
                |        |      E1      |        |-------  /
                |        |--------------|        |         --
                |   LE   |      E1      |  AN    |
                |        |--------------|        |        o--o
                |        |              |        |-------  /
                ----------              ----------         --

   LE and AN are connected with up to 16 E1 (PCM30) links.
   Channels 16, 15 and 31 on any E1 link can be reserved for
   data communication between LE and AN. The channels reserved
   for data are called "Communication Channels" or "C-
   Channels."

   The C-Channels are the physical media to exchange data
   between the V5.2 protocol peer entities, as well as to
   transfer the ISDN BRI D-Ch messages between the terminals
   and the LE. A logical communication path between two peer
   entities is called a "C-path".

   The signaling information in V5.2 are defined as:

        - Analog signals are carried by means of the V5 PSTN
          protocol (L3)

        - ISDN/analog ports are controlled by the V5 Control
          protocol (L3)

        - ISDN protocol messages are mapped to LAPD frames,
          which are carried by means of LAPV5-EF sublayer (L2)

Rao, Khanchandani, Ergincan, Weilandt,                         [page 5]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

        - V5 protocol messages are mapped to LAPV5-DL frames,
          which are carried by means of LAPV5-EF sublayer (L2)

   In order to support more traffic and dynamic allocation of
   links, the V5.2 protocol has several additions:

        - A bearer channel connection protocol establishes and
          de-establishes bearer connections required on demand,
          identified by the signalling information, under the
          control of the Local Exchange.

        - A link control protocol is defined for the multi-link
          management to control link identification, link
          blocking and link failure conditions.

        - A protection protocol, operated on two separate data
          links for security reasons, is defined to manage the
          protection switching of communication channels in
          case of link failures.

   The following protocols are defined for the various protocol
   layers:

        - LAPV5-EF

        - LAPV5-DL

        - V5-Link Control

        - V5-BCC

        - V5-PSTN

        - V5-Control

        - V5-Protection

2.1.4  Addition to boundary primitives

2.1.4.1  V5 specific boundary primitives

   V5.2 introduces new boundary primitives in addition to the
   ones defined for the Q.921/Q.931 boundary.

Rao, Khanchandani, Ergincan, Weilandt                          [page 6]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

   This includes new primitives between system management and
   the data link layer [2]:

   MDL-ESTABLISH

   The MDL-Establish primitives are used to request, indicate
   and confirm the outcome of the procedures for establishing
   multiple frame operation.

   MDL-RELEASE

   The MDL-Release primitive is used to indicate the outcome of

   the procedures for terminating multiple frame operation.

   MDL-LAYER_1_FAILURE

   The MDL-Layer_1_Failure primitive is used by the system
   management to indicate the condition of the physical layer
   to the data link layer.

2.2.0  Proposed V5.2 Backhaul Architecture

           ******   V5.2        ******      IP      *******
           * AN *---------------* SG *--------------* MGC *
           ******               ******              *******

           +-----+                                  +-----+
           |V5.2 |              (NIF)               |V5.2 |
           +-----+           +----------+           +-----+
           |     |           |     | IUA|           | IUA |
           |     |           |     +----+           +-----+
           |LAPV5|           |LAPV5|SCTP|           |SCTP |
           |     |           |     +----+           +-----+
           |     |           |     | IP +           | IP  |
           +-----+           +-----+----+           +-----+

   NIF  - Nodal Interworking function EP   - End Point SCTP -
   Stream Control Transmission Protocol IUA  - ISDN User Adaptation
   Layer Protocol

Rao, Khanchandani, Ergincan, Weilandt,                         [page 7]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

2.2.1.  IUA Message Header for V5.2

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tag (0x1)           |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Interface Identifier (integer)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            DLCI               |              Spare            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 2 Original IUA Message Header

   For the V5 extension of the IUA Message Header, the Envelope
   Function Address (EFA) field is included in the last 13 bits
   of the Spare field.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tag (0x1)           |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Interface Identifier (integer)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            DLCI               |     |          EFA            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 3 IUA Message Header for V5.2

   The EFA identifies a  C-path, which is a 13-bit number,
   ranging from 0 to 8191 (decimal). An EFA uniquely identifies
   one of the five V5.2 protocols, or an ISDN agent attached to
   an AN. The following list contains the possible values for
   the EFA

           Definition              Value
           ----------              ------
           ISDN_PROTOCOL           0 - 8175
           PSTN_PROTOCOL           8176
           CC_PROTOCOL             8177
           BCC_PROTOCOL            8178

Rao, Khanchandani, Ergincan, Weilandt                          [page 8]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

           PROT_PROTOCOL           8179
           LINK_CONTROL_PROTOCOL   8180
           RESERVED                8181 - 8191

2.2.2  V5 Additions to IUA Boundaries

   Primitives for the V5 interface are identified by the Message Class
   parameter in the Common Message Header for Q.921 user adaptation.
   The valid message class for V5 primitives is:

           6       Q.921/Q.932 Boundary Primitives Transport
                   Messages for V5 (QPTMV5)

   The boundary primitives that are defined for the Q.921/Q.931
   boundary are reused for the V5 messages. The following list
   contains the names of the messages valid for V5.2:

        Q.921/Q.931 Boundary Primitives Transport Messages

           1       Data Request Message
           2       Data Indication Message
           5       Establish Request
           6       Establish Confirm
           7       Establish Indication
           8       Release Request
           9       Release Confirm
          10       Release Indication

   The following new message is defined for the Q.921/Q.931
   boundary for V5 only:

          11       Layer 1 Failure Indication

2.2.3  V5 Layer 1 Failure Message

   The V5 Layer 1 Failure Message is used by the system manage-
   ment to indicate the data link layer that a layer 1 failure
   has occured. This primitive is send per protocol on a c-
   channel.
   The V5 Layer 1 Failure Message contains the common message
   header followed by IUA message header. It does not contain
   any additional parameters.

3.0  DUA

Rao, Khanchandani, Ergincan, Weilandt                          [page 9]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

3.1.1  Scope

   There is a need for Switched Circuit Network (SCN) signaling
   protocol delivery from a DPNSS Signaling Gateway (SG) to a Media
   Gateway Controller (MGC).  The delivery mechanism should support the
   following protocols:

          - DPNSS(Digital Private Network Signaling System)
          - DASS 2 (Digital Access Signaling System No 2)

   Unless specifically mentioned the details in this document are
   applicable to both DPNSS and DASS2.

3.1.2  Terminology

   Data channel (D-channel) - A 64 kbit/s time slot which functions
   as a common signaling channel on a 2048 kbits/s interface or a
   1544 kbits/s interface which is provisioned to carry DPNSS
   signaling.

   DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048
   kbits/s interface or Time slots 1 to 23 on a 1544 kbits/s
   interface are termed as DPNSS channels. These are the
   traffic channels which carry voice or data traffic.
    - DPNSS supports 60 Channels (30 Real and 30 Virtual)
    - DASS2 supports 30 Channels (All Real)

   Data Link Connection(DLC) - A DLC is the level 2 process that
   controls the transfer of level 3 messages on behalf of one
   DPNSS channel. A DLC uniquely identifies one DPNSS channel.
    - DPNSS supports 60 DLCs (30 Real and 30 Virtual)
    - DASSII supports 30 DLCs (All Real)

   DPNSS Link -  A logical collection of the D-channel and the
   associated DPNSS channels in a 2048 kbits/s interface or a
   1544 kbits/s interface is called a "DPNSS Link".

3.1.3  DPNSS Overview

   DPNSS is an industry standard interface (reference BTNR 188)
   defined between a PBX and an Access Network (AN).

   DPNSS extends facilities normally only available between
   extensions on a single PBX to all extensions on PBXs that are
   connected together in a private network. DPNSS was originally
   derived from BT's Digital Access Signaling System I (DASS I)

Rao, Khanchandani, Ergincan, Weilandt                         [page 10]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

   enhanced where necessary to meet the private network requirements.
   Some of these enhancements were incorporated in DASS 2.
   DPNSS uses a 2048 kbits/s or 1544 kbits/s Digital Transmission
   System Interface as shown in figure 1 below.

        ----------              ----------        o--o
        |        | 2048 kbits/s |        |-------  /\
        |        |--------------|        |         --
        |  PBX   | 1544 kbits/s |  AN    |
        |        |--------------|        |        o--o
        |        |              |        |-------  /\
        ----------              ----------         --
                        Figure 1

   Channels 16 on a 2048 kbits/s interface and channel 24 on a
   1544 kbits/s interface is reserved for data communication
   between LE and AN. The channels reserved for data are called
   "Data Channels" or "D-Channels."

   The D-Channels are the physical media to exchange data
   between the DPNSS protocol peer entities.
   A logical collection of the D-channel and the
   associated DPNSS channels is called a "DPNSS Link".

3.1.4  Proposed DPNSS Backhaul Architecture

        ******   DPNSS       ******      IP      *******
        *PBX *---------------* SG *--------------* MGC *
        ******               ******              *******

        +-----+                                  +-----+
        |DPNSS|              (NIF)               |DPNSS|
        | L3  |                                  | L3  |
        +-----+           +----------+           +-----+
        |     |           |     | DUA|           | DUA |
        |DPNSS|           |DPNSS+----+           +-----+
        | L2  |           | L2  |SCTP|           |SCTP |
        |     |           |     +----+           +-----+
        |     |           |     | IP +           | IP  |
        +-----+           +-----+----+           +-----+

   NIF  - Nodal Interworking function
   SCTP - Stream Control Transmission Protocol
   DUA  - DPNSS User Adaptation Layer Protocol

3.2.0  Changes from IUA

Rao, Khanchandani, Ergincan, Weilandt,                        [page 11]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

    The following section outlines the differences between DUA and IUA

3.2.1  Message Header

   IUA Message header has the format as shown in Figure 2 below.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tag (0x1)           |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Interface Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            DLCI               |              Spare            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 2 IUA Message Header

   In DUA header DLCI field has a different format in accordance with
   the BTNR 188.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Indicator   |0|Channel No.|1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The indicator field is used to determine whether the message is for
   a particular DLC or it is applicable for all the DLCs in the
   carrier. The possible values of the indicator is mentioned below.

       Value          Description

         0            Action is to be performed on all DLCs
                      Channel number parameter is ignored.

         1            Action is to be performed on a single
                      DLC specified by channel number.

   This indicator value is used only by the Est and Rel messages.
   Data messages should ignore this value.
   This indicator is provided so that a single command can be issued to
   establish or release all the DLCs in one DPNSS Link.

Rao, Khanchandani, Ergincan, Weilandt,                        [page 12]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2, DPNSS/DASS 2                         November 2000

   For channel number the valid values are 0 to 63 for DPNSS and 0 to
   31 for DASS 2. This is because DASS 2 does not support virtual DLCs
   and hence has only 32 DLCs.

3.2.2  Adaptation Layer Identifier

   Adaptation Layer Identifier string must be set to "DUA" for the DUA
   applications.

3.2.3  Unit Data Message

   DPNSS layer 2 does not have a unit data primitive and hence the
   Unit Data Messages (Request, Indication) are invalid for a DUA
   application.

3.2.4  Status Message

   IUA MIUA-TEI STATUS Message has the following format:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Status                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In DUA this will be known as the Status message and will have the
   following format.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
DLC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 1  |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |16
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17  |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |32
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
33  |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |48
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
49  |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |64
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   These 4 words carry the status of DLCs using two bits for each DLC.
   These are the possible values for these two bits.

       Value          Description
         00        Out Of Service
         01        Reset Attempted
         10        Reset Completed
         11        Information Transfer

Rao, Khanchandani, Ergincan, Weilandt,                        [page 13]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

   For DASS 2 there are no virtual DLCs and hence information about
   only 32 DLCs need to be carried. Therefore the status message will
   have only 2 words instead of 4 for DPNSS.

   For DASS 2 the value 00 (Out Of Service) is invalid since the DASS 2
   DLC does not have this state.

3.2.5  Error Message

   The ERR message is sent when an invalid value is found in an
   incoming message.

   The Error Code parameter indicates the reason for the Error Message.
   These are the supported values in IUA.

        Invalid Version                        0x1
        Invalid Interface Identifier           0x2
        Invalid Adaptation Layer Identifier    0x3
        Invalid Message Type                   0x4
        Invalid Stream Identifier              0x5
        Unassigned TEI                         0x6
        Unrecognized SAPI                      0x7
        Invalid TEI, SAPI combination          0x8
        Invalid AS Mode Type                   0x9

   In DUA the error codes 0x6 to 0x8 are invalid as they are specific
   to ISDN.

   The following additional error codes are supported in DUA.

        Channel Number out of range            0xA
        Channel Not configured                 0xB

3.3.0  IANA Considerations

   A request will be made to IANA to assign a DUA value for the Payload
   Protocol Identifier in SCTP Payload Data chunk. The following SCTP
   Payload Protocol Identifier will be registered:

   The SCTP Payload Protocol Identifier is included in each SCTP Data
   chunk, to indicate which protocol the SCTP is carrying. This Payload
   Protocol Identifier is not directly used by SCTP but may be used by
   certain network entities to identify the type of information being
   carried in a Data chunk.

   The User Adaptation peer may use the Payload Protocol Identifier as

Rao, Khanchandani, Ergincan, Weilandt,                        [page 14]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

   a way of determining whether the message is for IUA or DUA.

3.4.0 Message Sequence in DUA

   An example of the message flows for establishing a data link on a
   signaling channel, passing PDUs and releasing a data link on a
   DPNSS channel is shown below. An active association between MGC
   and SG is established prior to the following message flows.

3.4.1 Resetting of single DLC

   i)  Successful

        PBX                     SG                        MGC
             <----------- SABMR            <----------- Est Req(Ind=1)
        UA   ----------->          Est Cfm -----------> (DLC in RC
   State)
                                   (Ind=1)

   ii) Unsuccessful(Link Failure)

        PBX                     SG                        MGC
             <----------- SABMR            <----------- Est Req(Ind=1)
             Retransmissions over
             NT1 and NT2 expired
                                 Rel Ind -----------> (DLC in RA state)
                             (RELEASE_PHYS,Ind=1)

3.4.2 Resetting all DLCs in a link

        PBX                     SG                        MGC

             <----------- SABMR(1)         <----------- Est Req(Ind=0)
             <----------- SABMR(2)
             <----------- SABMR(3)
            .............
             <----------- SABMR(N)
             In each DLC either
             UA is received or
             NT1/NT2 is expired
                                 Est Cfm -----------> (Status of DLCs
                                 (Ind=0)               are not updated)
                                         <----------- Stat Req
                                 Stat Res -----------> (Mark DLC status
                                                  based on status bits)

3.4.3  Information Transfer on a DLC

Rao,Khanchandani,Ergincan, Weilandt                           [page 15]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

        PBX                     SG                        MGC
             <----------- UI(C)            <----------- Data Req
        UI(C)----------->         Data Ind ----------->

3.4.4  Link Takedown(Single DLC)

        PBX                     SG                        MGC
               (For DPNSS, mark DLC as OOS)   <----------- Rel Req
               (For DASSII, mark DLC as RA)    (RELEASE_MGMT,Ind=1)
                                  Rel Cfm  ---------->
                                  (Ind=1)

3.4.5  Link Takedown(All DLCs)

        PBX                     SG                        MGC
               (For DPNSS, mark all DLCs as OOS) <----------- Rel Req
               (For DASSII, mark all DLCs as RA)  (RELEASE_MGMT,Ind=0)
                                  Rel Cfm  ---------->
                                  (Ind=0)

3.4.6  Getting link Status

        PBX                     SG                        MGC
                                         <----------- Stat Req
                                 Stat Res -----------> (Mark DLC status
                                                  based on status bits)

3.4.7  Error conditions
        PBX                     SG                        MGC
                           Invalid Message -----------
   Est/Rel/Data/Stat Req
                               Error Ind   ----------->
                              (Error Code)

3.4.8  Glossary of terms

       Real channel   : The signalling channel with associated
                        traffic channel (TS).
       Virtual channel: The signalling channel with no
                        associated traffic channel.
       NT1            : Retransmission period of 500msec.
       NT2            : Recommended value is 64.

Rao, Khanchandani, Ergincan, Weilandt                         [page 16]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

4.0  References

   [1]  ISDN Q.921-User Adaptation Layer <draft-ietf-sigtran-
        iua-09.txt>

   [2]  EN 300 324-1 (1999): V interfaces at the digital Local
        Exchange (LE); V5.1 interface for the support of Access
        Network (AN); Part 1: V5.1 interface specification.

   [3]  EN 300 347-1 (1999): V interfaces at the digital Local
        Exchange (LE); V5.2 interface for the support of Access
        Network (AN); Part 1: V5.2 interface specification.

   [4]  ETS 300 125 (1991) : DSS1 protocol; User-Network inter-
        face data link layer specification; (Standard is based
        on : ITU Q.920, Q.921).

   [5]  ETS 300 166 (08/1993) : Transmission and Multiplexing;
        Physical and electrical characteristic of hierarchical
        digital interfaces (Standard is based on G.703).

   [6]  ETS 300 167 (08/1993) : Transmission and Multiplexing;
        Functional characteristic of 2048 kbits/s interfaces
        (Standard is based on G.704, G.706).

   [7]  BTNR (British Telecom Network Requirements) 188 Issue 6
        Digital Private Network Signaling System 1

   [8]  BTNR (British Telecom Network Requirements) 190 Issue 2
        Digital Access Signaling System No 2

5.0  Authors' Addresses

5.1  V5UA Authors

   Sanjay Rao                               Tel +1-919-991-2251
   Nortel Networks             Email rsanjay@nortelnetworks.com
   35 Davis Drive
   Research Triangle Park, NC 27709
   USA

   Neeraj Khanchandani                      Tel +1-919-991-2274
   Nortel Networks             Email neerajk@nortelnetworks.com
   35 Davis Drive
   Research Triangle Park, NC 27709

Rao, Khanchandani, Ergincan, Weilandt,                        [page 17]
Vydyam, Mukundan, Mangalpally

Internet Draft V5.2 & DPNSS/DASS 2                        November 2000

   USA

   Dr. Fahir Ergincan                      Tel +49 7545 96 8844
   Nortel-Dasa Network Systems   Email fahir@nortelnetworks.com
   88039 Friedrichshafen
   Germany

   Dr. Eva Weilandt                        Tel +49 7545 96 7267
   Nortel-Dasa Network Systems   Email eva.weilandt@nortelnetworks.com
   88039 Friedrichshafen
   Germany

5.2  DUA Authors

   Authors : Anil Vydyam, Ranjith Mukundan and Narsimuloo Mangalpally

   All correspondence regarding DUA should be sent to
   the following address :

   Mick Dragon                            Tel. +44 1628 43 4388
   Nortel Networks plc        Email. mdragon@nortelnetworks.com
   Concorde Road
   Maidenhead
   Berkshire SL6 4AG
   United Kingdom

Rao, Khanchandani, Ergincan, Weilandt,                       [page 18]
Vydyam, Mukundan, Mangalpally



OpenSS7
SS7 for the
Common Man
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> SIGTRAN -> draft-rao-sigtran-v5ua-01
Last modified: Thu, 18 Dec 2008 06:35:36 GMT
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.