`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`INTERNATIONAL TELECOMMUNICATION UNION
`
`
`
`CCITT
`
`THE INTERNATIONAL
`TELEGRAPH AND TELEPHONE
`CONSULTATIVE COMMITTEE
`
`
`
`V.120
`(09/92)
`
`DATA COMMUNICATION
`OVER THE TELEPHONE NETWORK
`
`
`
`SUPPORT BY AN ISDN OF DATA TERMINAL
`EQUIPMENT WITH V-SERIES TYPE
`INTERFACES WITH PROVISION
`FOR STATISTICAL MULTIPLEXING
`
`
`
`
`
`
`Recommendation V.120
`
`
`Qualcomm Incorporated v. Rembrandt Wireless Techs. LP.
`IPR2020-00510
`Qualcomm Ex. 1065
`Page 1 of 40
`
`

`

`
`
`
`
`
`
`FOREWORD
`
`The CCITT (the International Telegraph and Telephone Consultative Committee) is a permanent organ of the
`
`International Telecommunication Union (ITU). CCITT is responsible for studying technical, operating and tariff
`questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide
`basis.
`
`The Plenary Assembly of CCITT which meets every four years, establishes the topics for study and approves
`
`Recommendations prepared by its Study Groups. The approval of Recommendations by the members of CCITT between
`Plenary Assemblies is covered by the procedure laid down in CCITT Resolution No. 2 (Melbourne, 1988).
`
`Recommendation V.120 was revised by Study Group XVII and was approved under the Resolution No. 2
`
`procedure on the 18th of September 1992.
`
`
`
`
`
`
`
`
`
`___________________
`
`CCITT NOTES
`
`In this Recommendation, the expression (cid:147)Administration(cid:148) is used for conciseness to indicate both a
`1)
`telecommunication administration and a recognized private operating agency.
`
`2)
`
`A list of abbreviations used in this Recommendation can be found in Annex B.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or
`mechanical, including photocopying and microfilm, without permission in writing from the ITU.
`
` ITU 1993
`
`Page 2 of 40
`
`

`

`Recommendation V.120
`
`Recommendation V.120 (09/92)
`
`SUPPORT BY AN ISDN OF DATA TERMINAL EQUIPMENT
`WITH V-SERIES TYPE INTERFACES WITH PROVISION
`FOR STATISTICAL MULTIPLEXING
`
`(revised 1992)
`
`1
`
`Scope
`
`This Recommendation describes a protocol that can be used for adapting terminals with non-ISDN standard
`
`network interfaces to an ISDN. It is intended to be used between two terminal adaptor (TA) functional groups, between
`two ISDN terminal (TE1) functional groups, between a TA and a TE1, or between either a TA or TE1 and an
`interworking facility inside a public or private ISDN. It provides for operation:
`
`a) over either circuit-mode or frame-mode connections;
`
`b) using either demand or semi-permanent establishment of communications; and
`
`c) over any of the following types of access channel:
`
`(cid:150)
`
`(cid:150)
`
`for circuit-mode connections: B, H0, H10 or H11
`for frame-mode connections: B, H0, H10, H11 or D.
`
`This Recommendation also describes how this protocol is related to synchronous and asynchronous interface
`
`specifications using the interchange circuits defined in Recommendation V.24. It is not intended to be a functional
`specification for an implementation of any system containing a TE1 or TA functional group. Except as explicitly noted,
`it is restricted to the definition of the protocol at the user-network interface (reference points S, T or U) and the ISDN-
`side interface of the interworking function (IWF).
`
`The terminal adaption protocol in this Recommendation may be used in support of three classes of non-ISDN-
`
`terminal protocols. These are:
`
`1) Asynchronous (start/stop) protocols, supported using the protocol sensitive asynchronous mode;
`
`2) Synchronous protocols using high level data link control procedure (HDLC) frame format, supported
`using the protocol sensitive synchronous mode;
`
`3) Synchronous protocols, supported using the bit transparent mode.
`
`The use of the bit transparent mode with frame mode connections is for further study.
`
`Application
`
`
`
`2
`
`2.1
`
`General
`
`The protocols described in this Recommendation may be used by a TE1, TA or IWF, as illustrated in
`
`Figure 1/V.120. The formats and procedures contained in this Recommendation are defined in terms of their operation
`across interfaces at reference points S, T or U, or (in the case of an IWF) across interfaces that may be internal network
`interfaces. Where necessary to promote compatibility, the relationship between the terminal adaption protocol and
`existing protocols at the interface at reference point R (where present) are also described.
`
`2.2
`
`Connectivity
`
`Two or more terminal adaption connections may be multiplexed across a circuit-mode bearer connection or
`
`frame-mode access connection. These connections are referred to in this Recommendation as (cid:147)logical links(cid:148). Logical
`links supporting different modes of the terminal adaption protocol may be multiplexed across the same circuit switched
`bearer connection or frame-mode access connection. Constraints on the number of logical links (up to the
`
`
`
`
`
`
`
`Recommendation V.120 (09/92)
`
`1
`
`Page 3 of 40
`
`

`

`maximum number that can be coded in the Address field) and the combinations of modes supported by a circuit switched
`bearer connection or frame-mode access connection are implementation dependent and are beyond the scope of this
`Recommendation.
`
`The protocol sensitive modes (1 and 2 above in § 1) of this Recommendation may be used to support
`
`dissimilar rates (i.e. when used between two TAs, the data rates at the interfaces at reference point R may be different).
`The use of buffering, application of the flow control protocol in this Recommendation, use of flow control procedures at
`the R reference point, use of discarding and other strategies for support of dissimilar rates are implementation dependent.
`
`Parameter exchange procedures may be defined to allow interworking between terminal adaptors (TAs) in an
`
`environment where multiple different TA protocols are used without requiring interworking functions within the
`network. Interworking between different types of TAs can be accomplished with multiprotocol terminal adaptors
`(MTAs) that are capable of supporting more than one protocol. However, interworking functions may be used when TAs
`are not capable of supporting more than one protocol.
`
`TE1
`
`TE2
`
`S/T
`
`S/T
`
`TE1
`
`R
`
`TA-V
`
`S/T
`
`ISDN
`
`S/T
`
`TA-V
`
`R
`
`TE2
`
`S/T/U
`
`IWF
`
`To national
`PSTN
`
`T1701440-92
`
`TE1
`TE2
`TA-V
`IWF
`S/T
`PSTN
`
`ISDN data terminal equipment
`Data terminal equipment (DTE) with non-ISDN interfaces
`V.120 terminal adapter supporting V-Series TE2s
`Interworking function
`S or T architectural reference points at which physical interfaces of concern may be implemented.
`Public switched telephone network
`
`FIGURE 1/V.120
`ISDN connection scenarios
`
`
`
`
`
`2.3.
`
`Protocol architecture
`
`Figure 2/V.120 shows the protocol architecture of the U-plane, defined for the purposes of this
`
`Recommendation. The protocol defined in this Recommendation may be viewed as having the physical layer and three
`sublayers: the core sublayer, the data link control sublayer and the adaption sublayer. The core sublayer and the data link
`control sublayer are subdivisions of the data link layer (see Recommendation X.212). The adaption sublayer may
`
`2
`
`Recommendation V.120 (09/92)
`
`Page 4 of 40
`
`

`

`also be considered a subdivision of the data link layer (though it may alternatively be viewed as a thin layer 3) This
`layering is in alignment with Recommendation I.233, (cid:147)ISDN frame mode bearer services(cid:148).
`
`
`
`
`
`Terminal adaptation sublayer
`
`Data link control sublayer
`
`Data link core sublayer
`
`Physical layer
`
`FIGURE 2/V.120
`
`Protocol layers used in this Recommendation
`
`
`
`Figure 3/V.120 shows how the layering of Figure 2/V.120 maps to the frame formats of this Recommendation.
`
`
`
`H
`
`CS
`
`Header
`
`Terminal adaptation data field
`
`Terminal adaptation field
`
`C
`
`Data link control information field
`
`Data link control field
`
`F
`
`A
`
`Data link core information field
`
`FCS
`
`F
`
`Data link core frame
`
`HDLC flag
`Address
`Frame check sequence
`Control (HDLC format)
`Header octet (optional for bit transparent mode)
`Optional header extension for control state information
`
`T1701450-92
`
`FIGURE 3/V.120
`Relationship between layering and frame formats
`
`
`
`S
`
`FAF
`
`CHC
`
`CS
`
`
`
`
`
`
`
`
`
`Recommendation V.120 (09/92)
`
`3
`
`Page 5 of 40
`
`

`

`2.3.1
`
`Terminal adaption sublayer
`
`The terminal adaption sublayer provides for transfer of data, provision for the detection of errors, and
`
`reassembly of segmented data between peer systems. It may also provide the following functions:
`1)
`segmentation;
`2)
`transport of notification of error conditions detected in external protocols (i.e. at the interface at reference
`point R);
`transport of information related to the normal operation of external products (e.g. break for the protocol
`sensitive asynchronous mode, HDLC idle for the protocol sensitive synchronous mode);
`support for operation with a network independent clock;
`flow control;
`transport of status information (which may be mapped to interchange circuits at the interface at reference
`point R; however, see Appendix II).
`
`4)
`5)
`6)
`
`3)
`
`2.3.2
`
`Data link control sublayer
`
`The data link control sublayer provides the procedures and formats of fields for data link layer peer-to-peer
`
`communication. The elements of procedures define the commands and responses that are used for peer-to-peer
`communication.
`
`
`
`For formats and the elements of procedures, see Recommendation Q.922.
`
`2.3.3
`
`Data link core sublayer
`
`
`
`
`
`The data link core sublayer allows for the statistical multiplexing of core information flows.
`
`The major core functions include:
`(cid:150)
`framing;
`(cid:150)
`transparency;
`(cid:150) multiplexing using the address field; and
`(cid:150)
`error detection.
`
`The data link core protocol is defined in Annex A of Recommendation Q.922. The data link core service is
`
`defined in Recommendation I.233.1.
`
`The HDLC frame at the S or T interface is referred to hereafter as the terminal adaption frame (it includes the
`
`HDLC address and control fields, the terminal adaption header and user data).
`
`2.4
`
`Operation over restricted transport capabilities
`
`Where a terminal adapter is used on an ISDN user interface for adaptation to a 64 kbit/s B-channel and the
`
`bearer capability provided by the ISDN is (cid:147)restricted(cid:148) 64 kbit/s, or the connection involves interworking with a 56 kbit/s
`network, the TA shall rate adapt to 56 kbit/s rate by using the first 7 bits of each B-channel octet and shall insert a binary
`ONE in the eighth bit of each B-channel octet as described in Recommendation I.464. The reverse process shall be used
`at a receiver. All of the procedures in this document are applicable to these transport capabilities as well as 64 kbit/s
`unrestricted transport capabilities.
`
`
`
`3
`
`Note (cid:150) In frame mode applications, the limitation, if it exists, will be in the access capability only.
`
`Terminal adaption protocol
`
`This section describes the terminal adaption protocol. This protocol depends upon the services of the data link
`
`control sublayer and, for the bit transparent mode, it also depends upon the services of the physical layer (clock).
`
`There are two categories of terminal adaption defined in this Recommendation. Protocol sensitive operation
`
`requires that the TE1, TA or IWF be able to identify the beginning and end of characters or HDLC frames, removing
`
`4
`
`Recommendation V.120 (09/92)
`
`Page 6 of 40
`
`

`

`any idle time fill. Bit transparent operation provides for the transport of isochronous data transparently without
`alignment (above the bit level) of information from the interface at the R reference point within the frame transport in
`the bearer channel. It is particularly suited to the adaption of protocols that are not covered by the protocol sensitive
`modes.
`
`Two protocol sensitive modes are defined for the terminal adaption protocol. The asynchronous mode is
`
`intended to transport start/stop mode data. The synchronous mode is for the transport of HDLC framed data.
`
`3.1
`
`Formats
`
`The terminal adaption header may contain one or two octets. The two are labelled the header (H) octet and the
`
`control state (CS) octet.
`
`3.1.1
`
`H-header octet
`
`The H octet is mandatory for the protocol sensitive modes of operation, and is optional for the bit transparent
`
`mode. The format of the H octet is shown in Figure 4/V.120. Its presence in the bit transparent mode is negotiated
`during call setup for demand connections or by prior agreement for semi-permanent connections.
`
`Bit
`
`1
`F
`T1701460-92
`
`
`
`8
`E
`
`7
`BR
`
`6
`res
`
`5
`res
`
`4
`C2
`
`3
`C1
`
`2
`B
`
`Extension bit
`Break/mark hold bit
`Error control bits
`Segmentation bits
`Reserved for future standardization
`
`EB
`
`R
`C1, C2
`B, F
`res
`
`FIGURE 4/V.120
`Header octet format
`
`
`
`3.1.1.1
`
`E-extension bit (bit 8)
`
`The E-bit is the header extension bit. It allows the extension of the header to provide additional control state
`
`information. A (cid:147)0(cid:148) bit indicates that a control state (CS) information octet follows (see § 3.1.2).
`
`3.1.1.2
`
`BR asynchronous-break/HDLC-idle bit (bit 7)
`
`In asynchronous applications, the break bit indicates the invocation of the BREAK function by the TE2.
`
`A (cid:147)1(cid:148) in this bit position indicates BREAK (see §§ 3.2.1.1 and 7.2).
`
`In protocol sensitive operation for synchronous HDLC applications the BR bit is used to indicate whether
`
`an HDLC idle condition exists at the R reference point. A (cid:147)1(cid:148) in this position indicates that an HDLC idle condition (all
`binary 1s) exists. In bit transparent mode this bit is reserved and must be set to (cid:147)0(cid:148) on transmission and ignored on
`reception.
`
`3.1.1.3
`
`Bits 5 and 6
`
`
`
`
`
`Bits 5 and 6 of the header octet are reserved and must be set to (cid:147)0(cid:148).
`
`
`
`
`
`Recommendation V.120 (09/92)
`
`5
`
`Page 7 of 40
`
`

`

`3.1.1.4
`
`C1, C2 error control bits (bits 3 and 4)
`
`Bit 3 and bit 4 of the header octet are defined as control 1 and control 2, respectively, and are used for TA
`
`error detection and transmission.
`
`
`
`The meanings of the C1 and C2 bits are encoded as shown in Table 1/V.120.
`
`TABLE 1/V.120
`
`Coding of C1- and C2-bits
`
`
`
`C1
`
`C2
`
`Synchronous
`
`Asynchronous
`
`Bit transparent
`
`0
`
`0
`
`1
`
`1
`
`0
`
`1
`
`0
`
`1
`
`No error detected
`
`No error detected
`
`No error detected
`
`FCS error
`(interface at R)
`
`Abort
`
`Stop-bit error
`
`Not applicable
`
`Parity error on the last
`character in frame
`
`Not applicable
`
`TA overrun (from interface
`at the R reference point)
`
`Both Stop-bit and parity
`error
`
`Not applicable
`
`3.1.1.5
`
`B, F segmentation bits (bit 2 and bit 1)
`
`
`
`The B and F bits are used for segmenting and reassembly of user HDLC frames in synchronous mode
`
`applications. Setting the B bit to (cid:147)1(cid:148) indicates that the terminal adaption (TA) frame contains an information portion
`signifying the start of a message. Setting the F bit to (cid:147)1(cid:148) indicates the TA frame contains the final portion of the user
`frame. If the entire message is contained within a single TA frame then both B and F bits shall be set to (cid:147)1(cid:148). A TA frame
`which is neither first nor last is termed a middle frame. For the asynchronous mode and the bit transparent mode these
`bits are set to (cid:147)1(cid:148). The meaning of the B and F bits is summarized in Table 2/V.120.
`
`TABLE 2/V.120
`
`Coding of B and F bits
`
`B
`
`1
`
`0
`
`0
`
`1
`
`F
`
`0
`
`0
`
`1
`
`1
`
`Synchronous
`
`Begin frame
`
`Middle frame
`
`Final frame
`
`Single frame
`
`Asynchronous
`
`Bit transparent
`
`Not applicable
`
`Not applicable
`
`Not applicable
`
`Not applicable
`
`Not applicable
`
`Not applicable
`
`Required
`
`Required
`
`
`
`
`
`6
`
`Recommendation V.120 (09/92)
`
`Page 8 of 40
`
`

`

`3.1.2
`
`CS-control state octet
`
`The control state information is contained in the second octet of the header when present. The format of the
`
`control state information octet is shown in Figure 5/V.120. For TAs, this field may carry physical interface control
`information, (see § 3.2.3 for procedures). When unnumbered information (UI) frames are used for data transfer, this
`field may be used to provide for flow control (see § 3.2.4.1 for flow control). The CS octet should be expected any time
`the H-field is present and is extended to two octets. The following shows the format of the control state information
`octet. For an example of the mapping of the V.24 leads, see Appendix II. See § 3.2.3 for the procedures and see § 3.2.4.1
`for the use of the RR bit for flow control.
`
`8
`E
`
`7
`DR
`
`6
`SR
`
`5
`RR
`
`4
`res
`
`3
`res
`
`2
`res
`
`Bit
`
`1
`res
`T1701470-92
`
`Extension bit
`Data ready
`Send ready
`Receive ready
`Reserved for future standardization
`
`ED
`
`R
`SR
`RR
`res
`
`FIGURE 5/V.120
`Control state information octet
`
`
`
`
`
`3.1.2.1
`
`E-extension bit (bit 8)
`
`Because the control state information octet is the second and last octet in the Header, the E bit shall be set
`
`to (cid:147)1(cid:148). The receipt of a control state octet with the E bit set to (cid:147)0(cid:148) shall be considered an error.
`
`3.1.2.2
`
`Data ready (DR) (bit 7)
`
`
`
`This bit set to (cid:147)1(cid:148) indicates that the interface at the R reference point is activated (e.g. DTR ON).
`
`3.1.2.3
`
`Send ready (SR) (bit 6)
`
`
`
`This bit set to (cid:147)1(cid:148) indicates that the TE is ready to send data.
`
`3.1.2.4
`
`Receive ready (RR) (bit 5)
`
`
`
`This bit set to (cid:147)1(cid:148) indicates that the TE is ready to receive data.
`
`3.1.2.5
`
`Bits 4, 3, 2, 1
`
`
`
`Bits 4, 3, 2, and 1 of the control state information octet are reserved and shall be set to (cid:147)0(cid:148).
`
`3.1.3
`
`Interframe time fill
`
`Interframe time fill at the S-interface should normally be HDLC flags. For special non-D-channel applications
`
`it may be all (cid:147)1s(cid:148). On the D-channel of a basic access, the transmitted interframe time fill shall be
`all (cid:147)1s(cid:148).
`
`
`
`
`
`
`
`Recommendation V.120 (09/92)
`
`7
`
`Page 9 of 40
`
`

`

`3.2
`
`Procedures
`
`Operating modes (cid:150) general
`3.2.1
`In order to ensure data integrity in the synchronous (HDLC) and asynchronous modes of operation, it is
`
`strongly recommended that, where practical, the multiple frame acknowledged information ((cid:147)I(cid:148)) transfer procedure be
`used.
`
`Protocol sensitive operation in the asynchronous mode
`3.2.1.1
`To send data to a peer terminal adaption protocol entity, characters shall be encapsulated in a TA frame. The
`
`parity bit, if present, may be encapsulated or omitted (except as noted in § 7.2). The start and stop bits shall not be
`encapsulated. More than one character may be encapsulated in a TA frame. The decision to forward a TA frame is
`implementation dependent. The setting of the bits C1 and/or C2 to (cid:147)1(cid:148) shall indicate that the TA (or IWF) has detected a
`stop bit error and/or a parity bit error (R reference point), respectively. If either bit is set, the TA frame shall be
`transmitted without the encapsulation of additional characters. Similarly, the BR bit set to (cid:147)1(cid:148) by the terminal adaption
`protocol entity shall indicate a break. The TA frame shall be forwarded without encapsulating further characters. The BR
`bit set to (cid:147)0(cid:148) by the terminal adaption protocol entity shall indicate the end of a break.
`
`When a terminal adaption protocol entity receives a frame, it may disassemble it into characters or accumulate
`it into units appropriate for internal use. Handling of stop bit errors, parity errors and break is implementation specific
`(except that additional procedures are noted in § 7 and Appendix I for TA functional groups and TE1s, respectively).
`
`Protocol sensitive operation in the synchronous (HDLC) mode
`3.2.1.2
`HDLC frames, including the address, control and information fields shall be encapsulated in one or (if
`
`segmentation1) and reassembly are used) more terminal adaption frames and forwarded to the peer terminal adaption
`protocol entity. In addition, if the unacknowledged mode of the data link control service is used, the FCS shall also be
`encapsulated. The C1 and/or C2 bits set according to Table 1/V.120 shall indicate that the TA functional group or IWF
`detected an FCS error, an HDLC abort, or an overrun (at the R interface or internal interface). When the C1 and/or
`C2 bits are set, the frame shall be forwarded. To indicate an HDLC idle condition (i.e. continuous marking), the terminal
`adaption protocol entity shall send a frame containing the BR bit set to (cid:147)1(cid:148). To indicate the end of an HDLC idle
`condition (i.e. resumption of sending of flags), the terminal adaption protocol entity shall send a frame containing the
`BR bit set to (cid:147)0(cid:148).
`
`When a terminal adaption protocol entity receives a frame, reassembly of segments may be necessary. If either
`or both of the C1 and C2 bits is set to (cid:147)1(cid:148), the terminal adaption protocol entity may:
`a) discard the frame and all previously received segments;
`b)
`abort the HDLC frame being sent across the R interface or internal (virtual) interface; or
`c) generate an incorrect FCS in the HDLC frame being sent across the R interface or internal interface.
`Note 1 (cid:150) Support of non-octet-aligned frames is for further study.
`
`Note 2 (cid:150) Alternatives (b) and (c) are not meaningful if the terminal adaptation protocol entity is in a TE1.
`
`Note 3 (cid:150) When adapting 56 kbit/s HDLC terminals to 64 kbit/s B-channels, using unacknowledged data
`
`transfer, the value of N2120 should not exceed 64 bytes. A high probability of overflow in the direction of transmission
`towards the S or T interface side of a TA may occur if a large proportion of the frames are shorter than 64 bytes and
`there is no idle period between them. In such cases, restrictions, such as flow control of the TE2, may be necessary.
`
`_______________
`1) Segmentation and reassembly may reduce assembly delay associated with terminal adaption.
`
`8
`
`Recommendation V.120 (09/92)
`
`Page 10 of 40
`
`

`

`Bit transparent operation
`3.2.1.3
`Bits shall be encapsulated in frames and forwarded without modification. The maximum length of individual
`
`frames shall not be greater than N201, but otherwise is implementation dependent2). Longer frames will increase transit
`delay attributable to terminal adaption.
`
`When a frame is received, the content of the data field is handled as a bit stream. A TA functional group or
`IWF shall not modify the bit stream.
`
`Use of the unacknowledged mode of the Data Link Control service is preferred for bit transparent operation, as
`delay variance due to retransmission of I frames might result in underrun. Bit transparent operation is for further study.
`
`Data field length
`3.2.2
`The maximum number of octets in a data field (N2120) is a system parameter. Its value must be less than or
`
`equal to N201 (see Recommendation Q.922) minus the length of the header. Negotiation procedures for N201 are
`discussed in Recommendation Q.922.
`
`CS information processing
`3.2.3
`This subsection describes the use of the control state variables and the processing of the CS information field,
`
`when present, defined in § 3.1.2. Use of the CS information field is optional (see in § 6.3.2.4.5 octet 5b, bit 7 of low
`layer compatibility). The procedures described below in this section and in its sub-sections only apply if the control state
`information field is used.
`
`The terminal adaptation protocol provides for six control state variables (to be maintained by the TA protocol
`entity) that are related to the DR, SR, and RR indicators as follows:
`1)
`send variables DR(S), SR(S), and RR(S) (cid:150) when a frame with DR, SR, and RR is transmitted, their
`transmitted values shall be equal to the current values of DR(S), SR(S), and RR(S), respectively;
`receive variables DR(R), SR(R), and RR(R) (cid:150) when a frame with DR, SR, and RR is received, the receive
`variables are set to the values of these indicators, respectively.
`The control state information field may be included even if control state variables are not changed. The
`
`use of the control state information field with UI frames is not recommended except for flow control as mentioned
`in § 3.1.2.
`
`2)
`
`Control state information initialization
`3.2.3.1
`The first I or UI frame sent by each peer (after link initialization) shall contain the control state information
`
`octet. This exchange shall occur immediately following link verification. If the first frame does not contain the control
`state, the values of all of the bits should be assumed to be (cid:147)1(cid:148); i.e. until a frame containing the CS bits is received,
`DR(R), SR(R) and RR(R) should be set to (cid:147)1(cid:148).
`
`Sending a control state information field
`3.2.3.2
`A control state information field shall be sent whenever a send control state variable changes. The control state
`
`information field shall be sent in the last frame containing any of that previously queued data (received across the
`interface at the R reference point) prior to the control state variable change, or in a separate frame.
`
`The contents of the control state information octet shall be set to the state of the corresponding send control
`state variables. DR is set to DR(S), SR is set to SR(S), and RR to RR(S).
`
`_______________
`2) As discussed in Appendix III, clock recovery at the receiver may depend upon frames being of uniform length and transmitted at
`uniform intervals.
`
`
`
`
`
`
`
`Recommendation V.120 (09/92)
`
`9
`
`Page 11 of 40
`
`

`

`3.2.3.3
`
`Receiving a control state information field
`
`Upon receipt of a control state information field, the control field indicators shall be compared with the receive
`
`control state variables: DR to DR(R), SR to SR(R), and RR to RR(R). The receive control state variables shall be set to
`their received indicator values.
`
`If SR(R) was (cid:147)0(cid:148) and the SR indicator bit in the received control state information field is (cid:147)1(cid:148), then the state of
`
`RR(S) is set to state of SR(R) provided that the peer entity is not being flow controlled by use of the RR(S) state (see §
`3.2.4.1).
`
`If SR(R) was (cid:147)1(cid:148), and the SR indicator bit in the received control state information field is (cid:147)0(cid:148), then the RR(S)
`
`state is set to SR(R).
`
`Note (cid:150) Where the control state variables are used for control of the interface at the R reference point, the
`
`changes in the state of RR(S) should be consistent with one of the following:
`
`1)
`
`2)
`
`3)
`
`if received data (from peer entity) does not remain to be forwarded, then the control actions can occur
`immediately;
`
`if received data (from peer entity) is incomplete (e.g. in protocol sensitive mode the final frame was not
`received) and DR(R) is (cid:147)1(cid:148), then the incomplete message is forwarded (continued) until delivered on the
`interface at the reference point, at which time the control actions may occur;
`
`if received data (from peer entity) is complete, then the received data is forwarded until delivery on the
`interface at the R reference point is complete, at which time the control actions should occur.
`
`If DR(R) was (cid:147)0(cid:148) and the DR indicator bit in the received control state information field is (cid:147)1(cid:148), then DR(R) is
`
`
`set to 1.
`
`If DR(R) was (cid:147)1(cid:148) and the DR bit in the received control state information field is (cid:147)0(cid:148), then DR(R)
`
`is set to (cid:147)0(cid:148).
`
`Note (cid:150) Where the control states variables are used for control of the interface at the R reference point, the
`
`changes in the state of DR(R) should be consistent with the following:
`
`1)
`
`2)
`
`If the received user frame from the peer entity is incomplete, it is discarded.
`
`If the received user frame from the peer entity is a complete user frame, then it should be delivered prior
`to the control actions taking place.
`
`3.2.4
`
`Data flow control and buffering
`
`Strategies for buffering, forwarding and flow control are implementation dependent. This section describes the
`
`mechanisms in the data link control and terminal adaption protocols for asserting flow control between peer terminal
`adaption protocol entities. The specific protocol mechanisms are dependent on the mode of operation.
`
`3.2.4.1
`
`Protocol sensitive asynchronous mode
`
`When the multi-frame mode of the data link control protocol is used, flow control between peer
`
`terminal adaption protocol entities may be asserted by the data link control sublayer. The applicable data link control
`protocol mechanisms are: sending a receive not ready (RNR) frame, or withholding the update of the sequence state
`variable V(R).
`
`When the unacknowledged mode is used, flow control between peer terminal adaption protocol entities may be
`
`asserted by setting the RR bit in the control state information octet (if available). Flow control is asserted by sending a
`control state information field with the RR bit set to (cid:147)0(cid:148). The flow control condition is removed by sending a control
`state information field with the RR bit set to (cid:147)1(cid:148). Frames containing only the H and C octets may be sent even if flow
`control has been asserted by the peer terminal adaption protocol entity. Use of the RR bit for this purpose may be
`mutually exclusive from its mapping to V.24 interchange circuits required for support of half duplex operation
`(see Appendix II).
`
`Note (cid:150) In some applications, local flow control procedures (e.g. in the protocol used at the interface at
`
`reference point (cid:147)R(cid:148)) may be used. The use of these procedures is implementation dependent. Examples of such
`procedures include signalling using V.24 interchange circuits and use of the (cid:147)XOFF(cid:148) and (cid:147)XON(cid:148) characters.
`
`10
`
`Recommendation V.120 (09/92)
`
`Page 12 of 40
`
`

`

`3.2.4.2
`
`Protocol sensitive synchronous mode
`
`In protocol sensitive synchronous mode, overrun and underrun conditions are possible in a TA functional
`
`group (i.e. at the interface at reference point (cid:147)R(cid:148)) or IWF (i.e. at the interface at the non-ISDN side of the IWF).
`Procedures at the interface at reference point (cid:147)R(cid:148) are described in § 7.3.
`
`If, after transmitting one or more segments of a frame to the peer terminal adaption protocol entity, it becomes
`
`necessary to abort the transmission of the remainder of the frame, the (cid:147)H(cid:148) octet of the last segment to be sent shall have
`the B- and F-bits set to (cid:147)final(cid:148) (see Table 2/V.120) and the C1- and C2-bits set to (cid:147)TA overrun(cid:148) (see Table 1/V.120).
`Additional segments of the frame shall be discarded. (This procedure is intended for use by a TA functional group or
`IWF in the case of an overrun at the interface at reference point R, or at the interface at the non-ISDN side of the IWF,
`respectively. An underrun condition towards the R reference point may result in the sending of an abort or by forcing an
`FCS error.)
`
`As flow control in HDLC involves elements of procedure not supported by the terminal adaption protocol,
`
`internal overflow conditions may be handled by discarding user frames. Recovery from lost frames will be between
`users (e.g. between TE2s).
`
`3.2.4.3
`
`Bit transparent mode
`
`In bit transparent mode, overrun and underrun conditions may occur if buffers are inadequate and/or
`
`inappropriate clock recovery capabilities are provided. Dissimilar rates between users (e.g. TE2s) are not possible.
`
`Note 1 (cid:150) Underrun conditions may be treated as the equivalent of the mark hold condition (e.g. by sending
`
`continuous marks across the interface at reference point (cid:147)R(cid:148)).
`
`Note 2 (cid:150) If a terminal adaptation protocol entity is unable to process data to be sent to its peer (e.g. because of
`
`buffer overflow) it may discard as much data as it is unable to process.
`
`3.2.5
`
`Parameter negotiation
`
`Parameter negotiation during the bearer channel establishment is in accordance with the procedures described
`
`in Recommendation Q.931 for circuit mode operation and Recommendation Q.933 for frame mode operation. During
`logical link negotiation, a specific value for a parameter may be requested by including the low layer compatibility
`information element containing the desired parameters in the SETUP message. The receiving TA may accept the
`requested parameter values by responding with a CONNECT message. If