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 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 (). 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 [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