JP-3GA-27.

003(R99) Terminal Adaptation Functions (TAF) for services using Synchronous bearer capabilities

Version 3

May 14, 2001

THE TELECOMMUNICATION TECHNOLOGY COMMITTEE

JP-3GA-27.003(R99) Terminal Adaptation Functions (TAF) for services using synchronous bearer capabilities
Remarks

1. Application level of English description

Application level : E3 English description is included in the text and figures of main body, annexes and appendices.

2. Relationship with international recommendations and standards

This standard is standardized based on the Technical Specification 27.003(Version 3.5.0) approved by 3GPP in Dec. 2000.

3. Departures from international recommendations

3.1 Selection of optional items None

3.2 Items of national matter None

3.3

Changes to original standard (1) Standards referred to in the original standard, which are replaced by TTC/ARIB standards. Refer to Table 1. (2) Items added to the original standard None (3) Items deleted from None (4) Items changed from the original standard None

3.4

Difference in chapter ordering from the original standard. There is no difference in chapter ordering from the original standard.

4. Change history

Revision
V.1 V.2

Date
Mar.31,2000 Nov.30,2000 Newly standardized

Contents

Revised based on the Technical Specification 27.003 (Version 3.4.0) approved by 3GPP

V.3

May.14,2001

Revised based on the Technical Specification 27.003 (Version 3.5.0) approved by 3GPP

-3GA-27.003(R99)

5. IPR
There is no specific description about IPR in this standard.

6. Others
None

Table 1 original standard 3G TS 22.002

Replaced standards referred replacement ARIB STANDARDS ARIB STD-T63-22.002 Title : IMT-2000 DS-CDMA System Circuit Bearer Services (BS) supported by a Public Land Mobile Network (PLMN)

Title : Circuit Bearer Services (BS) supported by a Public Land Mobile Network (PLMN)

3G TS 24.008 Title : Mobile Radio Interface Layer 3 specification; Core Network Protocols Stage 3 3G TS 27.001 Title : General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS) 3G TR 21.905 Title : Vocabulary for 3GPP Specification ITU-T RECOMMENDATIONQ.931 Title : ISDN user-network interface layer 3

TTC STANDARDS JP-3GA-24.008 (R99) Title : Mobile Radio Interface Layer 3 specification; Core Network Protocols Stage 3 TTC STANDARDS JP-3GA-27.001 (R99) Title : General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS) TTC TECHNICAL DOCUMENT JP-3GA-21.905 (R99) Title : Vocabulary for 3GPP Specification TTC STANDARDS JT-Q931 Title : ISDN user-network interface layer 3 specification for basic call control TTC STANDARDS JT-V110 Title : Support of data terminal equipments with V-series interface by an integrated services digital network

specification for basic call control ITU-T RECOMMENDATIONV.110 Title : Support of data terminal equipments with V-series interface by an integrated services digital network ITU-T RECOMMENDATIONX.32 Title : Interface between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for terminals operating in Packet Mode and accessing a PSPDN through a PSTN or an ISDN or a CSPDN 3G TS 23.910 Title : Circuit Switched Data Bearer Services 3G TS 27.002 Title : Terminal adaptation functions (TAF) for services using asynchronous bearer capabilities

TTC STANDARDS JT-X32 Title : Interface between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for terminals operating in Packet Mode and accessing a PSPDN through a PSTN or an ISDN or a CSPDN TTC STANDARDS JP-3GA-23.910 (R99) Title : Circuit Switched Data Bearer Services TTC STANDARDS JP-3GA-27.002(R99)

Title : Terminal adaptation functions (TAF) for services using asynchronous bearer capabilities

ii

-3GA-27.003(R99)

3GPP TS 27.003 V3.5.0 (2000-09)

Technical Specification

3rd Generation Partnership Project; Technical Specification Group Core Network; Terminal Adaptation Functions (TAF) for services using synchronous bearer capabilities (Release 1999)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organisational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organisational Partners accept no liability for any use of this Specification. Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organisational Partners' Publications Offices.

Release 1999

3GPP TS 27.003 V3.5.0 (2000-09)

Keywords
UMTS, GSM, terminal, adaption

3GPP Postal address 3GPP support office address

650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet
http://www.3gpp.org

Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.
2000, 3GPP Organizational Partners (ARIB, CWTS, ETSI, T1, TTA,TTC). All rights reserved.

3GPP

Release 1999

3GPP TS 27.003 V3.5.0 (2000-09)

Contents
Foreword ......................................................................................................................................................5 1 2
2.1 2.2

Scope..................................................................................................................................................6 References...........................................................................................................................................6
Abbreviations....................................................................................................................................................8 Definitions ........................................................................................................................................................8

3
3.1 3.2 3.3

General ...............................................................................................................................................9
Customer access configuration ..........................................................................................................................9 Terminal Adaptation Function ..........................................................................................................................9 TAF Interfacing to other MT functions..............................................................................................................9

Terminal Adaptation Functions for synchronous transparent services .................................................10

4.1 Rate Adaptation in GSM .................................................................................................................................10 4.1.1 Rate adaptation - ITU-T V-series ...............................................................................................................10 4.1.2 Rate adaptation - ITU-T X.21 ....................................................................................................................10 4.1.3 Rate adaptation - ITU-T S-interface ...........................................................................................................10 4.2 Interchange Circuit Signalling Mapping .........................................................................................................10 4.2.1 ITU-T V-series interchange circuit mapping ..............................................................................................10 4.2.1.1 Multislot configurations (Channel coding TCH/F9.6 or TCH/F4.8 kbit/s) ..................................................13 4.2.1.2 Channel coding TCH/F14.4 and TCH/F28.8 ..............................................................................................13 4.2.2 ITU-T X.21 [23] Interchange circuit mapping............................................................................................13 4.2.3 Case of ITU-T S-interface ..........................................................................................................................13 4.3 Call establishment signalling mapping at TE/MT interface .............................................................................13 4.3.1 ITU-T V-series interfaces...........................................................................................................................13 4.3.1.1 Call establishment manual operation - utilizing Alternate Speech/Data or Speech followed by Data Capabilities .....................................................................................................................................13 4.3.1.2 Call establishment manual operation - utilizing the Unrestricted Digital Capability...................................14 4.3.1.3 ITU-T V.25 bis [18]auto call/auto answer ..................................................................................................14 4.3.2 ITU-T X-series interfaces...........................................................................................................................14 4.3.3 ITU-T S-interface (ITU-T I.420 [11]) signalling mapping..........................................................................14 4.3.4 X.25 Procedures Mapping..........................................................................................................................14

5
5.1 5.1.1 5.1.2 5.2 5.2.1 5.2.2 5.3 5.3.1 5.3.2 5.3.3 5.4 5.4.1 5.4.2

Terminal Adaptation Functions for synchronous non-transparent services...........................................15

Rate Adaptation and protocol model................................................................................................................15 ITU-T R-interface ......................................................................................................................................15 ITU-T S-interface ......................................................................................................................................15 Signalling Mapping (GSM only) .....................................................................................................................15 Interchange circuit signalling mapping ......................................................................................................15 Call establishment signalling mapping.......................................................................................................16 Flow Control ...................................................................................................................................................16 Conditions requiring flow control towards the network ..............................................................................16 Conditional requiring flow control towards TE2 ........................................................................................17 Local flow control ......................................................................................................................................17 Buffers ............................................................................................................................................................17 TX buffers .................................................................................................................................................17 RX buffers .................................................................................................................................................17

6
6.1 6.2

V-series interface procedures to 3GPP TS 24.008 [7] mapping ..........................................................18

Mobile Originated calls ...................................................................................................................................18 Mobile Terminated calls..................................................................................................................................18

3GPP

Release 1999

3GPP TS 27.003 V3.5.0 (2000-09)

7 8

ITU-T X.21 [23] interface procedures to 3GPP TS 24.008 [7] mapping.............................................19 Support for packet service .................................................................................................................19

Annex A (normative): L2R Functionality..................................................................................................20 A.1 A.2 A.3

A.3.1 A.3.2 A.3.3 A.3.4 A.3.5 A.3.6

Introduction.......................................................................................................................................20 L2RBOP...........................................................................................................................................20 Use of the L2RBOP ..........................................................................................................................22

Radio Link Connection Control .................................................................................................................22 Status transfer............................................................................................................................................23 LAPB connection control ...........................................................................................................................23 LAPB exchange identification....................................................................................................................23 Data Transfer.............................................................................................................................................23 Flow control...............................................................................................................................................23

Annex B (informative): Change history ....................................................................................................24

3GPP

Release 1999

3GPP TS 27.003 V3.5.0 (2000-09)

Foreword
This Technical Specification (TS) has been produced by the 3rd Generation Partnership Project (3GPP). The present document defines the interfaces and Terminal Adaptation Functions (TAF) integral to a Mobile Termination (MT) which enables the attachment of synchronous terminals to a MT within the 3GPP system. The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document.

3GPP

Release 1999

3GPP TS 27.003 V3.5.0 (2000-09)

Scope

The present document defines Terminal Adaptation Functions (TAF) which are integrated in a Mobile Termination (MT) and which enable the use of synchronous bearer services in the PLMN and the attachment of Synchronous synchronous Terminals terminals to an MT (see 3GPP TS 04.02 [3]). For the case where asynchronous terminals are attached to the TAF when using synchronous bearer services in the PLMN, the reader is referred to 3GPP TS 27.002 [36] for the asynchronous MT-TAF interface specifics and to the present document for synchronous bearer service specifics on the TAF-IWF interface. The general aspects of Terminal Adaptation Functions are contained in specification 3GPP TS 27.001 [9]. The present document covers support of synchronous data services (see 3GPP TS 22.002 [6]) for the following interfaces and procedures: V.22 [15] V.22 bis [16] V.26 ter [19] X.21 bis [24] X.32 [30] V.25 bis [18] DTE/DCE Interface; DTE/DCE Interface; DTE/DCE Interface; DTE/DCE Interface; Procedure; Procedure;

LAPB is the only synchronous non-transparent protocol which is considered in the present document. NOTE: From GSM R99 onwards the following services are no longer required by a GSM PLMN: the dual Bearer Services "alternate speech/data" and "speech followed by data"; the dedicated services for PAD and Packet access; BS 21 ... 26 and BS 31 ... 34.

The support of these services is still optional. The specification of these services is not within the scope of the present document. For that, the reader is referred to GSM Release 98.

References
References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. [1] [2] [3] [4] 3GPP TS 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and acronyms". 3GPP TS 03.10: "Digital cellular telecommunication system (Phase 2+); GSM Public Land Mobile Network (PLMN) connection types". 3GPP TS 04.02: "Digital cellular telecommunication system (Phase 2+); GSM Public Land Mobile Network (PLMN) access reference configuration". 3GPP TS 04.21: "Digital cellular telecommunication system (Phase 2+); Rate adaption on the Mobile Station - Base Station System (MS - BSS) interface".

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

3GPP

Release 1999

3GPP TS 27.003 V3.5.0 (2000-09)

[5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15]

3GPP TS 08.20: "Digital cellular telecommunication system (Phase 2+); Rate adaption on the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface". 3GPP TS 22.002: "Circuit Bearer Services (BS) supported by Public Land Mobile Network (PLMN)". 3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols-Stage 3". 3GPP TS 24.022: "Radio Link Protocol (RLP) for Circuit Switched Bearer and Teleservices". 3GPP TS 27.001: "General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)". 3GPP TR 21.905: "3G Vocabulary". ITU-T Recommendation I.420 (1998): "Basic user-network interface". ITU-T Recommendation Q.931: "ISDN user-network interface layer 3 specification for basic call control". ITU-T Recommendation V.10: "Electrical characteristics for unbalanced double-current interchange circuits operating at data signalling rates nominally up to 100 kbit/s". ITU-T Recommendation V.11: "Electrical characteristics for balanced double-current interchange circuits operating at data signalling rates nominally up to 10 Mbit/s". ITU-T Recommendation V.22 (1988): "1200 bits per second duplex modem standardized for use in the general switched telephone network and on point-to-point 2-wire leased telephone-type circuits". ITU-T Recommendation V.22 bis (1988): "2400 bits per second duplex modem using the frequency division technique standardized for use on the general switched telephone network and on point-to-point 2-wire leased telephone-type circuits". ITU-T Recommendation V.24 (1996):"List of definitions for interchange circuits between data terminal equipment (DTE) and data circuit-terminating equipment (DCE)". ITU-T Recommendation V.25 bis (1996): "Synchronous and asynchronous automatic dialling procedures on switched networks". ITU-T Recommendation V.26 ter (1988): "2400 bits per second duplex modem using the echo cancellation technique standardized for use on the general switched telephone network and on point-to-point 2-wire leased telephone-type circuits". ITU-T Recommendation V.28 (1993): "Electrical characteristics for unbalanced double-current interchange circuits". ITU-T Recommendation V.32 (1993): "A family of 2-wire, duplex modems operating at data signalling rates of up to 9600 bit/s for use in the general switched telephone network and on leased telephone-type circuits". ITU-T Recommendation V.110 (1996): "Support of data terminal equipments with V-Series interfaces by an integrated services digital network". Void. Void. ITU-T Recommendation X.24 (1988): "List of definitions for interchange circuits between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) on public data networks". ITU-T Recommendation X.26 (1993): "Electrical characteristics for unbalanced double-current interchange circuits operating at data signalling rates nominally up to 100 kbit/s".

[16]

[17] [18] [19]

[20] [21]

[22] [23] [24] [25]

[26]

3GPP

Release 1999

3GPP TS 27.003 V3.5.0 (2000-09)

[27] [28] [29] [30]

ITU-T Recommendation X.27 (1996): "Electrical characteristics for balanced double-current interchange circuits operating at data signalling rates up to 10 Mbit/s". Void. Void. ITU-T Recommendation X.32 (1996): "Interface between Data terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in packet mode and accessing a Packet-Switched Public Data Network through a public switched telephone network or an Integrated Services Digital Network or a Circuit-Switched Public Data Network". ISO/IEC Recommendation 8885: "Information technology - Telecommunication and information exchange between systems - High-level data link control (HDLC) procedures - General purpose XID frame information field content and format". ISO/IEC Recommendation 8886: "Information technology - Telecommunication and information exchange between systems - Data link service definitions for Open Systems interconnection". Personal Computer Memory Card Association: "PCMCIA 2.1 or PC-Card 3.0 electrical specification or later revisions". Infrared Data Association IrDA: "IrPHY Physical layer signalling standard". 3GPP TR 23.910: "Circuit Switched Data Bearer Services". 3GPP TS 27.002: "Terminal adaptation functions (TAF) for services using asynchronous bearer capabilities".

[31]

[32] [33] [34] [35] [36]

2.1

Abbreviations

In addition to the abbreviations listed below, the present document also uses termslisted in 3GTR 21.905 [10] and 3GPP TS 01.04 [1]. AU BORE EDGE FFS IrDA IrPHY ITU-T MUX PCMCIA PC Access Unit Bit Oriented Relay Entity Enhanced Data for Global Evolution For further studies Infrared Data Association InfraredPHYsical layer ITU-Telecommunication Standardization Sector Multiplexer Personal Computer Memory Card Association Personal Computer

2.2

Definitions

The term 'mobile station' (MS) in the present document is synonymous with the term 'user equipment' (UE ) in 3G terminology as defined in 3GPP TR 21.905. The term 'TE2' in the present document is synonymous with the term 'TE' in 3G terminology as defined in 3GPP TR 21.905. The term 'MT2' in the present document is synonymous with the term 'MT' in 3G terminology as defined in 3GPP TR 21.905.

3GPP

Release 1999

3GPP TS 27.003 V3.5.0 (2000-09)

3
3.1

General
Customer access configuration

The PLMN access reference configuration is described in figure 1 of 3GPP TS 04.02 [3] and 3GPP TS 27.001 [9]. The present document specifically refers to the MTs which support terminal equipments (TE1 or TE2) that use synchronous bearer capabilities.

3.2

Terminal Adaptation Function

The TAF is functionally part of an MT0, MT1 or MT2 (see 3GPP TS 04.02 [3]). The terminal adaptation provides facilities to allow manual or automatic call control functions associated with circuit switched data services, in case of ITU-T V series interfaces. The following functions are included:

conversion of electrical, mechanical, functional and procedural characteristics of the ITU-T V-series, type interfaces to those required by a PLMN; bit rate adaptation of ITU-T V-series and ITU-T X-series data signalling rates and the ISDN 64 kbit/s to that provided in the GSM PLMN; the mapping of ITU-T V.25 bis [18] AUTO CALL/AUTO ANSWER procedures to the PLMN Layer 3 signalling; the mapping functions necessary to convert ITU-T S-interface signalling to PLMN Layer 3 signalling; synchronization procedure, which means the task of synchronizing the entry to and the exit from the data transfer phase between two subscriber terminals. This is described in the specification 3GPP TS 27.001 [9]; filtering of channel control information. This is described in the specification 3GPP TS 27.001 [9]; compatibility checking (see 3GPP TS 27.001 [9]); layer 2 relaying (see annex 1); flow control; in Call Modification function (see clause 4); splitting and combining of the data flow in case of multi substream data configurations.

3.3

TAF Interfacing to other MT functions

Mobility Management TAF RR Management Channel Codec MMI Call Control Figure 1: TAF interfacing to other MT functions FEC

TAF interfacing is shown in figure 1.

3GPP

Release 1999

10

3GPP TS 27.003 V3.5.0 (2000-09)

Terminal Adaptation Functions for synchronous transparent services

Specification 3GPP TS 03.10 [2] refers to the models for connection types supporting synchronous transparent services.

4.1

Rate Adaptation in GSM

Rate adaptation on the MS-BS interface is described in 3GPP TS 04.21[4]. The synchronous data services make use of the following rate adaptation functions: RA1, RA2, RA1/RA1', RA1' and in case of TCH/F28.8 usage, EDGE-MUX. See also figures 6, 7 and 8 in 3GPP TS 03.10 [2]. The D-bits of the rate adaptation frames are used to convey user data and the S- and X-bits are used to convey channel status information associated with the data bits in the data transfer state, or to carry substream numbering between the Split/Combine functions in case of mult substream operation. For the S- and X-bits, a ZERO corresponds to the ON condition, a ONE to the OFF condition.

4.1.1

Rate adaptation - ITU-T V-series

This is provided as indicated in specification 3GPP TS 04.21 [4]. The functions applied in this case are shown in figure 2 (see model 2b in figures 6, 7 and 8 of 3GPP TS 03.10 [2]). Interface circuits (data and control) MT2 RA1' R Figure 2: Rate adaptation for V-series terminals

TE2 V-series

4.1.2
Void.

Rate adaptation - ITU-T X.21

4.1.3
Void.

Rate adaptation - ITU-T S-interface

4.2
4.2.1

Interchange Circuit Signalling Mapping

ITU-T V-series interchange circuit mapping

The interchange circuit signalling mapping at the interface between the TE2 and the MT shall conform to ITU-T recommendation V.24 [17]; while the signal levels at the interface shall conform either to ITU-T recommendation V.28 [20], or to IrDA IrPHY Physical signalling standard specification [34], or to PCMCIA 2.1 [33], or to PC-Card 3.0 [33] electrical specifications or to later revisions. The signals required at this interface are shown in table 2. Specification 3GPP TS 04.21 [4] refers to the frame structure and identifies the use of status bits for the carriage of signalling information.

Status bits SA, SB and X are used to convey channel control information associated with the data bits in the data transfer state. Table 1 shows the mapping scheme between the ITU-T V.24 [17]circuit numbers and the status bits for the transparent mode. It also shows how the unused status bits should be handled. It is derived from the general mapping scheme described in annex C. A binary 0 corresponds to the ON condition, a binary 1 to the OFF condition.

3GPP

Release 1999

11

3GPP TS 27.003 V3.5.0 (2000-09)

The transport of these status bits by the various channel codings is described in subsequent sections. Table 1: Mapping scheme at the MT for the transparent mode
Mapping Mapping Signal at TE2/MT direction: MT to IWF direction: IWF to MT interface or condition within the MT CT 105 not mapped (note 1) CT 106 from status bit X (note 7) CT 107 not mapped (note 5) CT 108/2 not mapped (note 6) CT 109 from status bit SB (note 7) CT 133 not mapped (note 2) always ON to status bit SA (note 3) always ON to status bit SB (note 1) always ON to status bit X (note 4) ignored by MT from status bit SA (note 3) NOTE 1: The SB bit towards the IWF, according to the General Mapping (27.002, annex C), could be used to carry CT 105. However, CT 105 should always be ON in the data transfer state since only duplex operation is supported. Also, many DTEs use the connector pin assigned to CT 105 for CT 133. No interchange circuit shall be mapped to the SB bit which shall always be set to ON in the data transfer state. NOTE 2: CT 133 is not mapped since there is no flow control in transparent mode. NOTE 3: The SA bits in both directions are available only with certain channel codings. Therefore, for maximum compatibility, they should not be mapped. NOTE 4: The X bit towards the IWF is not mapped and shall always be set to ON in the data transfer state since there is no flow control in transparent mode. NOTE 5: CT 107 is controlled by the channel synchronization process (3GPP TS 27.001 [9]). NOTE 6: CT 108/2 may be used in the call setup and answering processes. NOTE 7: The status bits are filtered before being mapped to the ITU-T V.24 [17] circuits (3GPP TS 27.001 [9]).

3GPP

Release 1999

12

3GPP TS 27.003 V3.5.0 (2000-09)

Table 2: Minimum set of V-series interchange circuits

Circuit Number Circuit Name Ground to TE2 CT102 CT103 Data from TE2 Control to from TE2 TE2

Common Return X Transmitted data X CT104 Received data X CT105 Request to send CT106 Ready for sending CT107 Data set ready CT108.2 Data terminal ready CT109 Data channel received line signal detector CT114 Transmitter signal element timing CT115 Receiver signal element timing CT125 Calling indicator (note) NOTE: CT125 is used with the AUTO ANSWER function of the TAF.

X X X X X X X X

Use of Network Independent Clocking (applicable to GSM only): Network Independent Clocking is only applicable to calls using ITC value "3.1 kHz audio ex PLMN". Within the GSM network the coding of the values for bits associated with NIC is specified in GSM specifications 3GPP TS 04.21 [4] and 3GPP TS 08.20 [5]. In the forward (transmitting) direction the multiframes shall be coded in exact accordance with that specified in those specifications. Bit E6 is set to "1" in alternate modified ITU-T V.110 [22] frames at the transmitter. However, the use of this bit at the receiver for monitoring frame Synchronization, or any other purpose, is not specified and is left to the discretion of the implementor. A "perfect linear block Code" is used in C1-C5, whose error correction properties may be utilized in the receiver, in order to ensure reliable operation of NIC. The NIC sending function has to recognize when the difference between the applicable clock speed of the GSM network and the interface speed generates a positive or negative whole bit requirement. When this positive or negative condition occurs, the NIC codewords specified in specification 3GPP TS 04.21 [4] are used to transport this condition to the receiving NIC function. Transmission of the codeword shall clear the positive or negative condition related to that codeword at the sending function. The sending function shall not send more than one positive or negative compensations within a contiguous period of time corresponding to 10 000 user data bits minus the number of user data bits necessary to make up an even number of ITU-T V.110 [22] frames between compensations (NIC compensation is coded in two ITU-T V.110 [22] frames). This results from the requirements to compensate for maximum clock differences of 100 parts per million. If the receiving function receives NIC compensations more often than a contiguous period of time corresponding to 10 000 user data bits, there is no guarantee that data will not be lost. The NIC receiving function has to provide the capability to support the compensation requirements of the sending function. This compensation is managed by manipulating the clock speed of the interface, within the standard constraints of that interface. Overall, the compensation functions have to be capable of managing clock tolerances of 100 parts per million. The NIC function has to recognize and manage the conversion of the NIC information received incoming from an ISDN terminal Interface. The conversion has to be made to the NIC format used within the GSM System as defined in

3GPP

Release 1999

13

3GPP TS 27.003 V3.5.0 (2000-09)

specifications 3GPP TS 04.21 [4] and 3GPP TS 08.20 [5]). The NIC function has to manage the conversion of the GSM NIC format into that used within the ISDN in the traffic direction towards the ISDN terminal interface. Due to the incompatibility between the ISDN and the GSM requirements NIC interworking is nor provided between these two formats. as such no NIC function is required in providing interworking to the ISDN for unrestricted digital. Action on loss of synchronization: If five consecutive NIC multiframes have incorrect framing bit values in E7, the receiver shall stop applying clocking compensation to the received data. Resynchronization shall be attempted and compensation shall resume when synchronization is achieved. Signal element timing: Receiver signal element timing (CT115) is generated by MT2. In the GSM transparent case, this shall be synchronized to the output of RA1' function. In the UMTS transparent case, this shall be synchronized to output of the RLC. In the non transparent case it is output from the L2R on the basis of the current user data rate. A transition from ON to OFF condition shall nominally indicate the centre of each signal element on CT104. Transmitter signal element timing is generated by MT2 (CT114), this may be synchronized to CT115. In the case of alternate Speech/Group 3 Facsimile, there may be a Channel Mode Modify during the course of the facsimile portion of the call. If this occurs, the user data rate changes and this is reflected to the ITU-T V.24 [17] interface as a change in the clock speed on CT 114 and CT 115.

4.2.1.1

Multislot configurations (Channel coding TCH/F9.6 or TCH/F4.8 kbit/s)

In transparent multislot configurations status bits S1, S3 and the X-bit between the D12 and D13 in the ITU-T V.110 [22] 80-bit intermediate rate frame - are used for transferring substream numbering information. The S4-bit is used for frame synchronization between the parallel substreams (ref 3GPP TS 04.21[4]).

4.2.1.2

Channel coding TCH/F14.4 and TCH/F28.8

For information on the mapping of the interchange circuit signalling bits in the 14,5 multiframe structure, refer to 3GPP TS 04.21 [4].

4.2.2
Void.

ITU-T X.21 [23] Interchange circuit mapping

4.2.3
Void.

Case of ITU-T S-interface

4.3
4.3.1
4.3.1.1
Void.

Call establishment signalling mapping at TE/MT interface

ITU-T V-series interfaces
Call establishment manual operation - utilizing Alternate Speech/Data or Speech followed by Data Capabilities

3GPP

Release 1999

14

3GPP TS 27.003 V3.5.0 (2000-09)

4.3.1.2

Call establishment manual operation - utilizing the Unrestricted Digital Capability

In this case the user shall not hear network supervisory tones or answer tone. The data transfer phase shall be entered automatically.

4.3.1.3

ITU-T V.25 bis [18]auto call/auto answer

The mapping of the ITU-T V.25 bis [18] procedures to the messages of the PLMN Layer 3 signalling (3GPP TS 24.008 [7]) is defined in clause 4. Auto Call: This procedure is provided according to ITU-T V.25 bis [18] using only circuit 108/2. A subset of ITU-T V.25 bis [18] is shown in table 4. This subset gives minimum level of control and indication. During the call establishment phase, i.e. after signalling, call tone according to ITU-T V.25 bis [18] shall be generated in the IWF, where appropriate. Auto Answer: This procedure is provided according to ITU-T V.25 bis [18]. Table 4: Minimum set of ITU-T V.25 bis [18] Call Set-up Commands and Indications
Commands from TE2 Indications to TE2 Description Call Request with Number provided 0,1..9,*,#,A,B,C,D Disregard Incoming Call Connect Incoming Call Call Failure Indication XX = CB,AB,NT,FC (Note) INcoming Call VALid INValid IA5Characters CRN DIC CIC CFI XX INC VAL INV

NOTE to table 4:

CB = Local MT busy AB = Abort call NT = No answer FC = Forbidden call (*)

(*)

Forbidden call indication results from contravention of rules for repeat call attempts as defined by the appropriate national approvals administration. It is recommended that this is the responsibility of the MT, not the TE2.

4.3.2
Void.

ITU-T X-series interfaces

4.3.3
Void.

ITU-T S-interface (ITU-T I.420 [11]) signalling mapping

4.3.4
Void.

X.25 Procedures Mapping

3GPP

Release 1999

15

3GPP TS 27.003 V3.5.0 (2000-09)

5
5.1
5.1.1

Terminal Adaptation Functions for synchronous non-transparent services.

Rate Adaptation and protocol model
ITU-T R-interface

For the protocol model and rate adaptation function applied in this case see Models 4b and 4e of figures 6, 7 and 8 in 3GPP TS 03.10 [2]) and 3GPP TS 23.910[35].

5.1.2
Void.

ITU-T S-interface

5.2
5.2.1

Signalling Mapping (GSM only)

Interchange circuit signalling mapping

Status bits SA, SB and X are used to convey channel control information associated with the data bits in the data transfer state. Table 5 shows the mapping scheme between the ITU-T V.24 [17] circuit numbers and the status bits for the non-transparent mode. It also shows how the unused status bits should be handled. It is derived from the general mapping scheme described in annex C. A binary 0 corresponds to the ON condition, a binary 1 to the OFF condition. The transport of the status bits by the L2RCOP is described in annex A.

3GPP

Release 1999

16

3GPP TS 27.003 V3.5.0 (2000-09)

Table 5: Mapping scheme at the MT for the non-transparent mode

Mapping Mapping Signal at TE2/MT direction: MT to IWF direction: IWF to MT interface or condition within the MT CT 105 not mapped (note 1) CT 106 (note 4) from status bit X (note 7) CT 107 not mapped (note 5) CT 108/2 not mapped (note 6) CT 109 from status bit SB CT 133 (note 8) To status bit X (notes 3,8) always ON to status bit SA (note 2) always ON to status bit SB (note 1) ignored by MT from status bit SA (note 2) NOTE 1: The SB bit towards the IWF, according to the General Mapping (27.002, annex C), could be used to carry CT 105. However, CT 105 should always be ON in the data transfer state since only duplex operation is supported. Also, many DTEs use the connector pin assigned to CT 105 for CT 133. No interchange circuit shall be mapped to the SB bit, which shall always be set to ON in the data transfer state. NOTE 2: The SA bits (both directions) are not mapped since CTs 107 and 108/2 are handled locally (notes 5 and 6). NOTE 3: The condition of status bit X towards the IWF may also be affected by the state of the receive buffer in the MT. NOTE 4: The state of CT 106 (or other local flow control mechanism) may also be affected by the state of the transmit buffer in the MT and the state of the RLP (RR/RNR). NOTE 5: CT 107 is controlled by the channel synchronisation process (3GPP TS 27.001 [9]). NOTE 6: CT 108/2 may be used in the call setup and answering processes. NOTE 7: For inband local flow control, changes in the condition of the status bit X from the IWF also result in the sending of XON or XOFF to the DTE. NOTE 8: For inband local flow control, CT 133 is not mapped and the status bit X towards the IWF is controlled by the reception of XON and XOFF characters from the DTE.

5.2.2
Void.

Call establishment signalling mapping

5.3
5.3.1

Flow Control
Conditions requiring flow control towards the network

The passage of flow control information between L2Rs is described in annex 1.

The L2R function shall send immediately a "flow control active" indication in the following circumstances: (i) if the receive buffer from the radio side reaches a preset threshold; (ii) if local flow control is initiated by the TE2 (see subclause 5.3.3 a)). On receipt of this flow control indication transmission of data from the receive buffer towards the TE2 is halted. On removal of the buffer congestion or local flow control the L2R shall send a "flow control inactive" indication. In addition, for the local flow control condition, transmission of data from the receive buffers shall be restarted.

3GPP

Release 1999

17

3GPP TS 27.003 V3.5.0 (2000-09)

5.3.2

Conditional requiring flow control towards TE2

The L2R function shall immediately activate local flow control (see subclause 5.3.3 b)) under the following circumstances: (i) the transmit buffer reaches a pre-set threshold; (ii) the L2R receives a "flow control active" indication. On removal of the buffer congestion or receipt of L2R/RLP "flow control inactive" the local flow control shall be removed.

5.3.3

Local flow control

Only inband flow control is allowed: a) from TE2: RNR is sent to indicate flow control active. RR is sent to indicate flow control inactive. Where RR/RNR is utilized then the TAF shall generate flow control active/inactive immediately.

b) from TAF: As from TE2. where this method is used, the L2R shall pass the RNR/RR frames to the TE2.

5.4
5.4.1

Buffers
TX buffers

Data received from the TE2 shall be buffered such that if the MT is unable to transfer the data over the radio path then data is not lost. The buffer shall be capable of holding n1 bytes. When the buffer is half full, TE2 shall be flow controlled as per subclause 5.3.2. The value for n1 is up to the implementors.

5.4.2

RX buffers

Data for transfer to the TE2 shall be buffered such that if the TE2 is unable to accept data then data transferred from the MT is not lost. The buffer size should be n2 bytes. The value for n2 is up to the implementors. When the buffer becomes half full, the L2R shall send a "flow control active" indication.

3GPP

Release 1999

18

3GPP TS 27.003 V3.5.0 (2000-09)

V-series interface procedures to 3GPP TS 24.008 [7] mapping

Interface procedures not directly mappable to 3GPP TS 24.008 [7] (ie. ITU-T V.25 bis [18] VAL/INV) are not considered. Mobile management procedures of 3GPP TS 24.008 [7] are not considered applicable. Mapping of other call establishment or clearing messages to the S interface e.g. "Call proceeding", etc. have not been included. It is assumed that these may be mapped directly and thus are of no relevance to the ITU-T V.25 bis [18] or manual interface.

6.1

Mobile Originated calls

Element MMI Derived from ITU-T V.25 bis [18] message CRN/CRI/CRS CRI

a) SET-UP.

Called Address Called Sub Address HLC LLC BC

Keypad Keypad

Derived from internal settings or MMI information. Same as HLC Same as HSC 3GPP TS 27.001 [9] gives allowed values

b) RELEASE COMPLETE.
Element Cause MMI Display (optional) Derived from ITU-T V.25 bis [18] message CFI

6.2

Mobile Terminated calls

Call establishment is initiated by receipt of Setup at the MS: a) SET-UP.

Element Called Address Called Sub Address HLC LLC BC MMI Display (optional) Display (optional) Display (optional) Display (optional) Display (optional) Mapped on to ITU-T V.25 bis [18] message INC Not applicable Not applicable Not applicable Not applicable

b) CALL CONFIRM. Information for the BC element in the call confirm is derived from e.g. MMI or by internal settings. c) CONNECT. Connect is sent in response, CIC from ITU-T V.25 bis [18] or in response from MMI.

3GPP

Release 1999

19

3GPP TS 27.003 V3.5.0 (2000-09)

7
Void.

ITU-T X.21 [23] interface procedures to 3GPP TS 24.008 [7] mapping

8
Void.

Support for packet service

3GPP

Release 1999

20

3GPP TS 27.003 V3.5.0 (2000-09)

Annex A (normative): L2R Functionality A.1 Introduction

This annex describes the Layer 2 Relay (L2R) functionality required to support LAPB non-transparently. The general aspects of L2Rs are described in specification 3GPP TS 27.001 [9]. Figure 1 shows the three sub-functions of the L2R.

BORE LAPB LAPB Entity L2RBOP Entity

L2RBOP

LAPB Link Access Protocol Balanced BORE Bit Oriented Relay Entity L2RBOP L2R Bot Oriented Protocol

Figure 1: Sub-functions of the L2R Clause 2 describes the L2R Bit Oriented Protocol (L2RBOP) and clause 3 describes the use of the L2RBOP to transport LAPB information fields.

A.2

L2RBOP

The LAPB user information fields and interface status changes are transferred between L2Rs using the services of the radio link. The L2RBOP entity segments and reassembles the LAPB user information fields to fit into the service data units (SDUs) handled by the radio link. I.e. segments of LAPB user information fields and interface status changes are transferred between L2Rs in n octet Protocol Data Units (PDUs). This corresponds to the fixed length of the RLP frame information field. The octets within the L2RBOP-PDU are numbered 0 to n-1, octet 0 is transmitted first. The value of n depends on the negotiated RLP version and frame type (3GPP TS 24.002 [8] ). The bits within the octets are numbered 1 to 8, bit 1 is transmitted first. The RLP version value 2 indicates RLP multi-link operation. The RLP version value 0 or 1 indicates RLP single-link operation. The L2RBOP also provides facilities for transferring LAPB connection control information between L2Rs. This LAPB connection control information allows concatenated LAPB connections to be established, reset and released. The L2RBOP PDUs are coded as follows: each octet contains a status octet, 1 - 8 bits of user information, control information or fill; octet 0 shall always contain a status octet in case at least one status octet is transportet in the L2RBOP PDU. In RLP-versions 0 and 1 a PDU always carries at least one status octet. In RLP version 2 a PDU carries status octet(s) only if actual status change(s) has taken place within the period represented by the PDU. Here the L2R status flag in the RLP version 2 header is set to 1 when status octet(s) is carried in the PDU;

3GPP

Release 1999

21

3GPP TS 27.003 V3.5.0 (2000-09)

status octets contain 3 status bits and 5 address bits. In cases where two status octets within the PDU are separated by more than 23 octets, the first status octet in octet m is followed by a pointer octet in octet m+1 forming a two-octet status field. The pointer octet contains one reserved bit and seven address bits indicating the number of characters between the status field and the second status octet; the 3 status bits are used to convey the interface conditions that are conveyed by the S and X bits in ITU-T recommendations V.110 [22]. In the case of ITU-T V series interfaces the 3 status bits correspond to SA, SB and X bits specified in ITU-T V.110 [22]. The ITU-T V series SA, SB and X bits use bit positions 8, 7 and 6 respectively in the status octets. The ITU-T X series S and X bits use bit positions 7 and 6 respectively, in this case bit position 8 is unused; LAPB user information is carried in L2RBOP-PDU information octets such that the first LAPB user information bit, in any consecutive group of 8, received or transmitted corresponds to bit position 1 in the octet. The second to bit position 2, etc.; information octets are inserted into the L2RBOP-PDU in order of arrival in octets 1 to n-1 for RLP single-link operation, in octets 1 to n-1 for RLP multi-link operation with status octet transportation and in octets 0 to n-1 for multi-link operation with no status octet transportation; the address field in the status octets indicates the position of the next status octet within the L2RBOP-PDU. This indicates the number of information octets between status octets. Thus if two status octets are inserted into an L2RBOP-PDU at offsets l and m the address field value for the status octet at offset 1 shall be defined by m-l-1 (m>l+1). The low order bit of the address corresponds to bit 1 of the octet and the high order bit to bit 5; status octets are inserted in the information stream whenever a status change needs to be transmitted; only address values 1 to n-2 (n-2 23) in the address field of status octets are used for addressing purposes. The implication of not allowing address value 0 to be used for addressing is that two status octets can not be sent after each other. The remaining codes are used to indicate: last status change, remainder of L2RBOP-PDU is empty. Address field value is 31; last status change, remainder of L2RBOP-PDU full of information octets. Address field value is 30; end of a LAPB user information field. Address field value is 29. This is used to delimit LAPB user information fields. In this case the 3 status bits do not have their usual meaning. They are used to indicate the number of information bits in the previous information octet. A binary number in the range 0 to 7 is contained in bit positions 8, 7 and 6, bit 6 is the low order bit. The values 1-7 indicates the number of information bits used, value 0 indicates all bits used. If this octet is not on the last position in a L2RBOP-PDU another status octet follows (e.g. an End of LAPB user information field in octet 0 is followed by a status octet in octet 1); abort a LAPB user information field transfer. The address field value is 28. This is used to abort the transmission of a LAPB user information field after sending one or more segments in L2RBOP-PDUs. If this octet is not on the last position in a L2RBOP-PDU another status octet is following (e.g. an Abort a LAPB user information field transfer in octet 0 is followed by a status octet in octet 1); L2RBOP-PDU contains at least two status octets which are separated by more than 23 characters; the address-field value in the first octet of the two-octet status field is 27 and the address bits in the pointer octet of the status field indicate the number of characters between the two-octet status field and the next status octet.

address field values from n-1 to 26 are reserved. In case of a PDU more than 25 octets in length, address field values from 24 to 26 are reserved. When it is necessary to insert a status octet into the information stream when no status change has occurred, e.g. to indicate that the remainder of an L2RBOP-PDU is empty or to indicate end of a LAPB user information field, the current status shall be repeated; in case when 64 data octets are carried by a 66-octet PDU, a status octet is carried in octet 0 and another status octet within the first 24 data octets. (The first status octet gives the address of the second status octet, which carries value 30 in its address field);

3GPP

Release 1999

22

3GPP TS 27.003 V3.5.0 (2000-09)

LAPB connection control information is transferred between L2Rs by use of a connection control PDU. Connection control PDUs consists of an L2RBOP PDU with the status octet in octet 0 containing address field value 0. The coding of the remainder of the L2RBOP connection control PDU is as follows: octet 1 contains the connection number, always 0 for LAPB. Other values are reserved for future use; octet 2 contains the connection control information. The connection control information values are 1 for Connect, 2 for Reset, 3 for Disconnect and 4 for loss of LAPB interframe fill. This octet is coded as a binary number with the low order bit corresponding to bit 1; the use of octets 3 to n-1 is reserved.

LAPB exchange identification frames (XID) are transferred between L2Rs by use of exchange identification PDUs. These PDUs consist of L2RBOP PDUs with the status octet in octet 0 containing address field values 0. The coding of the remainder of the PDU is as follows: octet 1 contains the connection number, always 0 for LAPB. Other values are reserved for future use; octet 2 contains the exchange identification indication. The values are 5 for an Exchange Identification Request and 6 for an Exchange Identification Acknowledge. The values 7 to 255 are reserved. This octet is coded as a binary number with the low order bit corresponding to bit 1; the octet 3 contains a normal status octet. The rest of the PDU and of the following PDUs, if any, is used to transfer the XID information and it is treated like normal user data information PDUs as far as the coding is concerned.

A.3
-

Use of the L2RBOP

LAPB entity - This terminates the LAPB protocol from the terminal or the network. The service provided by the LAPB entity to the BORE is described in ISO DIS 8886.2 [32] - OSI Data link service definition; L2RBOP entity - This uses the services provided by the radio link, see specification 3GPP TS 24.022 [8]. The service provided by the LAPB entity to the BORE; BORE - This concatenates the data link services provided by the use of the L2RBOP and LAPB.

The L2R function required to support LAPB non-transparently consists conceptually of the three sub-functions shown in figure 1, i.e. the LAPB entity, the BORE and the L2RBOP entity. These perform the following functions:

The functions are described in more detail in the following subclauses.

A.3.1

Radio Link Connection Control

The L2RBOP entity uses the services of the radio link to establish, reset and release the connection to its peer L2RBOP entity. The radio link connection shall be established and released as a result of indications from the signalling mechanisms when the supporting circuit switched connection is established. After an RLP reset or RLP disconnect the L2RBOP entities shall assume that the remote LAPB connection is in disconnected state. No data can therefore be transported between the L2RBOP entities before an exchange of the connection control PDU "Connect" has taken place. All connection control PDUs transferred before the RLP reset are no longer valid and must not be acknowledged. All PDUs (except XID) received by the L2RBOP entities after an RLP reset or disconnect and before a new connection control PDU "Connect" has been received shall be discarded by the L2RBOP entity.

3GPP

Release 1999

23

3GPP TS 27.003 V3.5.0 (2000-09)

A.3.2

Status transfer

The L2RBOP entity transfers interface status information between L2Rs via the status octets in the L2RBOP-PDUs. The meaning of the bits is exactly the same as that defined in ITU-T recommendation V.110 [22]. Status changes are inserted in the L2RBOP-PDU in the position corresponding to the position in the information stream at the DTE/DCE interface that the interface status change occurred. When the RLP is established or reset a L2RBOP-PDU with the current status octet shall be sent.

A.3.3

LAPB connection control

The L2RBOP entity transfers LAPB connection control information between L2Rs via the L2RBOP connection control PDUs. This allows a LAPB connection to be established, reset and released when the remote LAPB connection is established, reset and released or vice versa. L2RBOP connection control PDUs containing connect or reset requests shall be acknowledged by a similarly coded L2RBOP connection control PDU in the reverse direction. Data transfer between L2Rs is not allowed until the connection control acknowledge PDU is received. In the case of requests crossing they shall each be treated as acknowledgements of the other.

A.3.4

LAPB exchange identification

The L2RBOP entity transfers a LAPB exchange identification request/acknowledge between L2Rs via the L2RBOP exchange identification PDUs. This allows transfer of identification information prior to link establishment and/or during the link (especially with respect to ISO 8885 [31]/DADI). A L2RBOP exchange identification request PDU shall be answered by an associated exchange identification acknowledge PDU. In case of crossing of two requests each request shall be answered individually. A LAPB exchange identification request with identification information shall be acknowledged by the LAPB entity from L2R only when the acknowledge from the remote LAPB connection is indicated by an exchange identification acknowledge PDU sent by the remote L2RBOP entity.

A.3.5

Data Transfer

The L2RBOP entity assembles and disassembles L2RBOP-PDUs by segmenting and reassembling the LAPB user information fields.

A.3.6
-

Flow control

Flow control information is transferred between L2Rs in two ways, these are: back pressure caused by L2R buffer conditions; use of the X-bit in the status octet; X = 1 flow control active; X = 0 flow control inactive.

3GPP

Release 1999

24

3GPP TS 27.003 V3.5.0 (2000-09)

Annex B (informative): Change history

TSG CN# Spec Apr 1999 GSM 07.03 CN#03 27.003 CN#04 27.003 CN#06 27.003 CN#06 CN#07 CN#08 CN#09 27.003 27.003 27.003 27.003 CR Change history <Phase> Version New Version 6.0.0 3.0.0 R99 3.0.0 3.1.0 R99 3.1.0 3.2.0 R99 R99 R99 R99 3.1.0 3.2.0 3.3.0 3.4.0 3.2.0 3.3.0 3.4.0 3.5.0 Subject/Comment Transferred to 3GPP CN1 Approved at CN#03 Introduction of EDGE Introduction of Asynchronous interface for Real-time non-transparent FAX R99 service clean-up (also subclause 8.3 removed) UMTS clean up Adaptations for UMTS Modification from V.25bis to V.250

001 002 003 004 005 006

3GPP