ETSI ETS 300 946 ed.3 (1998-01)

Digital cellular telecommunications system (Phase 2+) (GSM); Radio Link Protocol (RLP) for data and telematic services on the Mobile Station - Base Station System (MS - BSS) interface and the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface (GSM 04.22 version 5.2.1)

RE/SMG-040422QR2

Digitalni celični telekomunikacijski sistem (faza 2+) – Protokol za radijsko povezovanje (RLP) podatkov in telematskih storitev o vmesniku sistema mobilna postaja-bazna postaja (MS-BSS) in vmesniku komutacijskega centra sistema bazne postaje-mobilne storitve (BSS-MSC) (GSM 04.22, različica 5.2.1)

General Information

• Status: Published
• Publication Date: 01-Feb-1998
• Technical Committee: SMG 4 - Data Services
• Current Stage: 12 - Completion
• Due Date: 30-Jan-1998
• Completion Date: 02-Feb-1998
• Ref Project: SIST ETS 300 946 E3:2003 - Digital cellular telecommunications system (Phase 2+) (GSM); Radio Link Protocol (RLP) for data and telematic services on the Mobile Station - Base Station System (MS - BSS) interface and the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface (GSM 04.22 version 5.2.1)

Standards Content (Sample)

SLOVENSKI STANDARD
01-december-2003
'LJLWDOQLFHOLþQLWHOHNRPXQLNDFLMVNLVLVWHPID]D±3URWRNRO]DUDGLMVNR
SRYH]RYDQMH5/3SRGDWNRYLQWHOHPDWVNLKVWRULWHYRYPHVQLNXVLVWHPDPRELOQD
SRVWDMDED]QDSRVWDMD06%66LQYPHVQLNXNRPXWDFLMVNHJDFHQWUDVLVWHPD
ED]QHSRVWDMHPRELOQHVWRULWYH%6606&*60UD]OLþLFD
Digital cellular telecommunications system (Phase 2+) (GSM); Radio Link Protocol (RLP)
for data and telematic services on the Mobile Station - Base Station System (MS - BSS)
interface and the Base Station System - Mobile-services Switching Centre (BSS - MSC)
interface (GSM 04.22 version 5.2.1)
Ta slovenski standard je istoveten z: ETS 300 946 Edition 3
ICS:
33.070.50 Globalni sistem za mobilno Global System for Mobile
telekomunikacijo (GSM) Communication (GSM)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN ETS 300 946
TELECOMMUNICATION January 1998
STANDARD Third Edition
Source: SMG Reference: RE/SMG-040422QR2
ICS: 33.020
Key words: Digital cellular telecommunications system, Global System for Mobile communications (GSM)
R
GLOBAL SYSTEM FOR
MOBILE COMMUNICATIONS
Digital cellular telecommunications system (Phase 2+);
Radio Link Protocol (RLP) for data and telematic services on the
Mobile Station - Base Station System (MS - BSS) interface
and the Base Station System - Mobile-services Switching Centre
(BSS - MSC) interface
(GSM 04.22 version 5.2.1)
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: [e-mail]
Tel.: [phone] - Fax: [phone]
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.
© European Telecommunications Standards Institute 1998. All rights reserved.

Page 2
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.

Page 3
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
Contents
Foreword .5
1 Scope .7
2 Normative references.7
2.1 Definitions and abbreviations.8
3 Introduction.9
4 Frame structure.10
4.1 Basic frame structure.10
4.2 RLP header.10
4.3 Order of transmission .10
4.4 Frame check sequence .10
5 Elements and procedure .11
5.1 Modes .11
5.1.1 Asynchronous Balanced Mode (ABM) .11
5.1.2 Asynchronous Disconnected Mode (ADM) .11
5.2 Header and parameters.11
5.2.1 Generally used bits.12
5.2.1.1 Command/response bit, C/R .12
5.2.1.2 Poll/Final bit, P/F.12
5.2.2 Unnumbered frames, U.13
5.2.2.1 Set asynchronous balanced mode SABM (11100).13
5.2.2.2 Unnumbered Acknowledge. UA (00110).13
5.2.2.3 Disconnect, DISC (00010).13
5.2.2.4 Disconnected Mode, DM (11000).13
5.2.2.5 Unnumbered Information, UI (00000).13
5.2.2.6 Exchange Identification, XID (11101) .13
5.2.2.7 Test, TEST (00111).14
5.2.2.8 Null information, NULL (11110) .15
5.2.2.9 REMAP (10001).15
5.2.3 Supervisory frames, S, and numbered information transfer and
supervisory frames combined, I+S.15
5.2.3.1 Numbering .16
5.2.3.2 Send Sequence number, N(S) .16
5.2.3.3 Receive sequence number, N(R) .16
5.2.3.4 L2R Status bit .16
5.2.3.5 Receive ready, RR (00) .16
5.2.3.6 Reject, REJ (01) .16
5.2.3.7 Receive not ready, RNR (10).17
5.2.3.8 Selective reject, SREJ (11).17
5.3 Error Recovery.17
5.3.1 Improper frames.17
5.3.2 N(S) sequence error.17
5.3.3 N(R) error .18
5.3.4 Time-out and checkpointing .18
5.3.4.1 Treatment of errors during link establishment, link reset
and link disconnect .18
5.3.4.2 Treatment of errors during numbered information transfer .18
5.3.5 Contentious situations .18
5.4 Transitions between TCH/F9.6 and TCH/F14.4 channel codings.18
5.5 List of system parameters.19
5.5.1 RLP Version N° .20
5.5.2 Maximum number of outstanding I frames k (Window size).20
5.5.3 Timer T1.20

Page 4
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
5.5.4 Maximum number of retransmissions N2. 20
5.5.5 Data Compression Parameters . 20
5.5.6 Re-sequencing period (Timer T4). 21
5.6 Support for discontinuous transmission (DTX) . 21
6 Service definitions. 21
6.1 Introduction. 21
6.2 Conventions . 21
6.3 Queue model. 22
6.4 List of Primitives . 23
6.5 Possible RLP time sequence diagrams . 24
Annex A (informative): RLP SDL Diagrams . 27
A.1 List of RLP entity states . 27
A.1.1 (main) states . 27
A.1.2 state variables . 27
A.2 List of RLP entity events . 31
History. 63

Page 5
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
Foreword
This European Telecommunication Standard (ETS) has been produced by the Special Mobile Group
(SMG) of the European Telecommunications Standards Institute (ETSI).
This ETS specifies the Radio Link Protocol (RLP) for data transmission over within the digital cellular
telecommunications system.
The specification from which this ETS has been derived was originally based on CEPT documentation,
hence the presentation of this ETS may not be entirely in accordance with the ETSI rules.
Transposition dates
Date of adoption of this ETS: 2 January 1998
Date of latest announcement of this ETS (doa): 30 April 1998
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 31 October 1998
Date of withdrawal of any conflicting National Standard (dow): 31 October 1998

Page 6
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
Blank page
Page 7
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
1 Scope
This European Telecommunication Standard (ETS) specifies the Radio Link Protocol (RLP) for data
transmission over the GSM PLMN. RLP covers the Layer 2 functionality of the ISO OSI Reference Model
(IS 7498). It is based on ideas contained in IS 3309, IS 4335 and IS 7809 (HDLC of ISO) as well as CCITT
X.25 and Q.92x (LAP-B and LAP-D of CCITT, respectively.) RLP has been tailored to the special needs of
digital radio transmission. RLP provides to its users the OSI Data Link Service (IS 8886).
RLP is intended for use with non-transparent data-transfer. Protocol conversion may be provided for a
variety of protocol configurations. Those foreseen immediately are:
- Character-mode protocols using start-stop transmission (IA5);
- X.25 LAP-B.
For reasons of better presentation, material about protocol conversion has been placed within those
Specifications concerned with the relevant Terminal Adaptors, i.e. GSM 07.02 for the asynchronous case
and GSM 07.03 for the synchronous case. Care must be taken that that material also applies to
Interworking Functions; see GSM 09.04 - 09.07.
2 Normative references
This ETS incorporates by dated and undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications
apply to this ETS only when incorporated in it by amendment or revision. For undated references, the
latest edition of the publication referred to applies.
[1] GSM 01.04 (ETR 350): "Digital cellular telecommunication system (Phase 2+);
Abbreviations and acronyms".
[2] GSM 04.21 (ETS 300 945): "Digital cellular telecommunication system; Rate
adaption on the Mobile Station - Base Station System (MS - BSS) interface".
[3] GSM 07.02 (ETS 300 914): "Digital cellular telecommunication system
(Phase 2+); Terminal Adaptation Functions (TAF) for services using
asynchronous bearer capabilities".
[4] GSM 07.03 (ETS 300 584): "Digital cellular telecommunication system
(Phase 2); Terminal Adaptation Functions (TAF) for services using synchronous
bearer capabilities".
[5] GSM 09.04: "Digital cellular telecommunication system; Interworking between
the Public Land Mobile Network (PLMN) and the Circuit Switched Public Data
Network (CSPDN)".
[6] GSM 09.05: "Digital cellular telecommunication system; Interworking between
the Public Land Mobile Network (PLMN) and the Packet Switched Public Data
Network (PSPDN) for Packet Assembly/Disassembly facility (PAD) access".
[7] GSM 09.06 (ETS 300 975): "Digital cellular telecommunication system
(Phase 2+); Interworking between a Public Land Mobile Network (PLMN) and a
Packet Switched Public Data Network/Integrated Services Digital Network
(PSPDN/ISDN) for the support of packet switched data transmission services".
[8] GSM 09.07 (ETS 300 976): "Digital cellular telecommunications system
(Phase 2+); General requirements on interworking between the Public Land
Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or
Public Switched Telephone Network (PSTN)".
[9] CCITT Recommendation I.440 (Redbook): "ISDN user-network interface data
link layer - General aspects".

Page 8
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
[10] CCITT Recommendation I.441 (Redbook): "ISDN user-network interface, data
link".
[11] CCITT Recommendation Q.920 (Redbook): "ISDN user-network interface data
link layer - General aspects".
[12] CCITT Recommendation Q.921 (Redbook): "ISDN user-network interface - data
link".
[13] CCITT Recommendation Q.921bis: "Abstract test suites for LAPD conformance
tests".
[14] CCITT Recommendation Q.922: "ISDN data link layer specification for frame
mode bearer services".
[15] CCITT Recommendation V.42bis: "Data Compression for Data Circuit
Terminating Equipment (DCE) using Error Correction Procedures".
[16] CCITT Recommendation X.25 (Redbook): "Interface between Data Terminal
Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for terminals
operating in Packet Mode and connected to Public Data Networks by dedicated
Circuit".
[17] ISO/IEC Recommendation 4335: "Information technology - Telecommunications
and information exchange between systems - High level data link control
(HDLC) procedures - Elements of procedures".
[18] ISO Recommendation 3309: "Information technology - Telecommunications and
information exchange between systems - High level data link control (HDLC)
procedures - Frame structure".
[19] ISO Recommendation 7498: "Information processing systems - Open Systems
Interconnection - Basic Reference Model".
[20] ISO 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".
[21] ISO Recommendation 8886: "Information technology - Telecommunication and
information exchange between systems - Data link service definitions for Open
Systems interconnection".
[22] ISO Recommendation 8509: "Information processing systems - Open Systems
Interconnection - Service conventions".
[23] ISO/IEC Recommendation 7809: "Information technology - Telecommunication
and information exchange between systems - High-level data link control
(HDLC) procedures - Classes of procedures".
[24] ISO Recommendation 7776: "Information processing systems - High-level data
link control procedures - Description of the X.25 LAPB-compatible DTE data link
procedures".
2.1 Definitions and abbreviations
Abbreviations used in this ETS are listed in GSM 01.04 [1].
For the purposes of this ETS, the following definitions apply:
backwards compatibility: RLP defines several backwards-compatible versions. That means that a
newer version can interwork with an older one without changing the older one. This is realized by a fall
back mechanism during XID exchange.

Page 9
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
command: An instruction represented in the RLP header, causing the receiving RLP entity to execute a
specific function.
frame check sequence: A field of redundant information based on a cyclic code, used for error detection.
I + S frame: An RLP frame that is used for user information transfer, carrying supervisory information
piggyback.
improper frame: An RLP frame having an FCS error or having a header the contents of which is
inconsistent with this Specification.
non-transparent: In PLMN data transmission, a configuration where at layer 2, protocol information of the
fixed network is mapped on RLP elements, and vice versa.
piggybacking: Means by which one and the same frame can carry both user information and RLP related
supervisory information.
response: A reply represented in the RLP-header, by which the sending RLP entity reports back about its
status.
RLP frame: A sequence of contiguous bits, representing an RLP procedural element.
RLP header: That part of an RLP frame that encodes either a command or a response, located at the
beginning of the RLP frame.
S frame: An RLP frame that contains supervisory information in the absence of user information.
transparent: In PLMN data transmission, a configuration where at layer 2 (and also at the layers above)
no protocol conversion takes place.
U frame: An RLP frame that contains unnumbered protocol control information.
3 Introduction
Three versions of RLP are defined:
- RLP version 0: single-link basic version;
- RLP version 1: single-link extended version (e.g. extended by data compression);
- RLP version 2: multi-link version
RLP uses one (single-link) or from 1 up to 4 (multi-link) physical links. However, the RLP multi-link version
is designed to be able to support up to 8 physical links. If, in the call setup signalling, either end indicates
that it cannot support multilink operation, neither end shall require usage of RLP-versions higher than 1.
RLP makes use of an underlying FEC (Forward Error Correction) mechanism. For RLP to perform
adequately it is assumed that the basic radio channel together with FEC provides for a block error rate of
less than 10 %, where a block consists of 240 or 576 bits (Further study on the BLER for 576-bit blocks is
needed). Furthermore, it is assumed that in case of multi-link RLP the difference of the delay between all
physical links is less than timer T4.
RLP frames are sent in strict alignment with the radio transmission. (For details, see GSM 04.21). RLP
frames are of a fixed size of 240 (TCH/F9.6 channel coding) or 576 bits (TCH/F14.4 channel coding).
Whenever a frame is to be sent, the RLP entity has to provide the necessary protocol information to be
contained in it. Provision is made for discontinuous transmission (DTX).
RLP spans from the Mobile Station (MS) to the interworking function (IWF), located at the nearest Mobile
Switching Centre (MSC), or beyond. Depending on the exact location of the IWF, handover of the MS may
result in link-reset or even total loss of the connection.
In the terminology of HDLC, RLP is used in a balanced configuration, employing asynchronous operation,
i.e. either station has the right to set-up, reset, or disconnect a link at any time. Procedural means are
provided for to deal with contentious situations, should they ever occur.
RLP is full-duplex in the sense that it allows for information to be transferred in both directions
simultaneously.
Page 10
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
4 Frame structure
4.1 Basic frame structure
An RLP-frame has a fixed length of either 240 or 576 bits consisting of a header, an information field, and
an FCS (frame check sequence) field. The size of the components depends on the RLP version and on
the RLP frame. As a benefit of using strict alignment with underlying radio transmission there is no need
for frame delimiters (like flags etc.) in RLP. In consequence, there is no "bit-stuffing" necessary in order to
achieve code transparency. Frames cannot be aborted while being transmitted.
Header Information FCS
version 0 and 1, version 2 (U frames 16/24 bit 200/192 bit 24 bit
only)
version 2 (S and I+S frames only) 24 bit 192 bit 24 bit
b) 576 bit frame size
Header Information FCS
version 0, 1, and version 2 (U frames 16 bit 536 bit 24 bit
only)
version 2 (S and I+S frames only) 24 bit 528 bit 24 bit
Figure 1: Frame structure
4.2 RLP header
An RLP-header carries one of three types of control information, the first being unnumbered protocol
control information (U frames), the second being supervisory information (S frames), the third being user
information carrying supervisory information piggybacked (I + S frames).
4.3 Order of transmission
The header, as defined in clause 5.2, shall be transmitted from left to right. The FCS shall be transmitted
commencing with the highest order term. The order of bit transmission for the information field is from left
to right.
4.4 Frame check sequence
The FCS shall be the ones complement of the modulo 2 sum of:
a) the remainder of:
For 9.6/4.8 kbit/s channel coding:
216 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4
x (x + x + x + x + x + x + x + x + x + x + x + x + x + x + x + x + x + x + x + x +
3 2
x + x + x + 1)
For 14.4kbit/s channel coding:
552 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
x (x + x + x + x + x + x + x + x + x + x + x + x + x + x + x + x + x
6 5 4 3 2
+ x + x + x + x + x + x + 1
divided modulo 2 by the generator polynomial:
24 23 21 20 19 17 16 15 13 8 7 5 4 2
x + x + x + x + x + x + x + x + x + x + x + x + x + x + 1

Page 11
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
and
b) the remainder of the division modulo 2 by the generator polynomial:
24 23 21 20 19 17 16 15 13 8 7 5 4 2
x + x + x + x + x + x + x + x + x + x + x + x + x + x + 1
of the product of x by the content of the frame, excluding the FCS field. (The first bit transmitted
corresponds to the highest order term.)
Implementation note: As a typical implementation, at the transmitter, the initial content of the register of
the device computing the remainder of the division is pre-set to all ones and is then modified by division by
the generator polynomial (as described above) of the header and information field; the ones complement
of the resulting remainder is transmitted as the 24 bit FCS sequence.
At the receiver, the initial content of the register of the device computing the remainder is pre-set to all
ones. The final remainder after multiplication by x and then division (modulo 2) by the generator
polynomial:
24 23 21 20 19 17 16 15 13 8 7 5 4 2
x + x + x + x + x + x + x + x + x + x + x + x + x + x + 1
of the serial incoming protected bits and the FCS will be:
23 0
0 1 1 0 1 1 0 1 1 0 0 0 1 0 0 1 0 0 1 1 0 0 0 0 (x to x , resp.)
in the absence of transmission errors.
5 Elements and procedure
5.1 Modes
An RLP entity can be in one of two modes:
- Asynchronous Balanced Mode (ABM)
- Asynchronous Disconnected Mode (ADM)
5.1.1 Asynchronous Balanced Mode (ABM)
In ABM, which is the data link operational mode, either RLP entity may send commands at any time and
may initiate response frame transmission without receiving explicit permission to do so from the other
RLP-station. In ABM, frames shall be used for information field transfer and/or to indicate status changes
in the RLP-station.
5.1.2 Asynchronous Disconnected Mode (ADM)
In ADM, which is the data-link non-operational mode, the RLP entity shall be logically disconnected from
the data link and shall, therefore, neither transmit nor accept numbered information frames.
The RLP entity shall, however, be permitted to transmit and accept NULL, DM, UI, TEST and XID frames.
Either RLP entity can issue an SABM command at any time, in order to terminate the ADM state. In that
case, entrance of the ABM state will be indicated by a UA response from the opposite station. If the
opposite station is not able to enter ABM, it will indicate this by a DM response. All commands other than
those mentioned above and any unsolicited response will be ignored in ADM under all circumstances.
5.2 Header and parameters
The formats defined for the header are listed in figure 2.

Page 12
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
5.2.1 Generally used bits
NOTES: C/R = COMMAND/RESPONSE BIT
P/F = POLL/FINAL BIT
X  = DON'T CARES
M M M M M
1 2 3 4 5
1 1 1 0 0 S A B M
0 0 1 1 0 U A
0 0 0 1 0 D I S C
S S 1 1 0 0 0 D M
1 2
0 0 R R 1 1 1 1 0 NULL
0 1 R E J 0 0 0 0 0 U I
1 0 R N R 1 1 1 0 1 X I D
1 1 S R E J 0 0 1 1 1 T E S T
1 0 0 0 1 REMAP
Versions 0 and 1:
NOTES: N(S) : Bit 4 low order bit
N(R) : Bit 11 low order bit
U C/R X X 1 1 1 1 1 1 P/F M1 M2 M3 M4 M5 X
______________ ______________
S C/R S1 S2 01 11 11 P/F N (R)
______________ ______________ ______________ ______________
I+S C/R S1 S2 N (S) P/F N (R)
bit 1 2 3 4 5 6 7 8 9 1011 1213 141516
Version 2:
NOTES: S = L2R Status Bit
N(S) : Bit 1 low order bit
N(R) : Bit 14 low order bit
U C/R X X 111111 P/FM1M2M3M4M5 X
______________  ______________
S X X X 011111 P/FC/RS1S2 N(R) XX
______________  ______________ ______________  ______________
I+S N(S) P/F C/R S1 S2 N(R) SX
bit 1 23456789 10 11 12131415161718192021222324
Figure 2: Header formats
5.2.1.1 Command/response bit, C/R
The C/R-bit is used to indicate whether the frame is a command or response frame and whether the
P/F-bit is to be interpreted as a poll or final bit, resp. For commands, the C/R bit shall be set to "1", for
responses it shall be set to "0".
5.2.1.2 Poll/Final bit, P/F
The P/F-bit is used to mark a special instance of command/response exchange. With a command, it is
called the P-bit, with a response, it is called the F-bit. In any one direction, only one P/F-bit exchange may
be outstanding at any time. A response with the F-bit set to "1" shall always reflect the latest receive status
of the RLP entity.
A P/F-bit exchange always starts with a command frame with the P-bit set to "1", which shall be answered
by a response frame with the F-bit set to "1" at the earliest response opportunity.

Page 13
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
No unsolicited F-bit = "1" is allowed. Such a frame shall be considered "improper" (see subclause 5.3.1).
In ABM, the use of the P/F-bit with numbered information exchange is only allowed for checkpoint-
recovery (see subclause 5.3.3).
5.2.2 Unnumbered frames, U
5.2.2.1 Set asynchronous balanced mode SABM (11100)
The SABM encoding is used as a command only. It is always used with the P-bit set to "1".
The SABM command is used either to initiate a link for numbered information transfer, i.e. to go from
ADM to ABM, or to reset a link already established for numbered information transfer. With an SABM
command, no information transfer is allowed.
When issuing an SABM, the RLP entity has set to zero its internal variables for sending and receiving
numbered information. The other RLP entity, on receiving an SABM command, will either confirm it by
setting to zero its internal variables for sending and receiving numbered information and then issuing an
UA (unnumbered acknowledgement) response or reject it by sending a DM (disconnected mode)
response. In the former case, both entities have entered ABM and numbered information transfer may
commence. In the latter case, both entities are in ADM.
When an SABM command is issued, a loss of information may occur. Appropriate action is in the
responsibility of the layers above.
5.2.2.2 Unnumbered Acknowledge. UA (00110)
The UA encoding is used as a response only. It is used to positively acknowledge an SABM or DISC
command. With the UA response, no information transfer is allowed.
5.2.2.3 Disconnect, DISC (00010)
The DISC encoding is used as a command only. It is used to disestablish a link, previously established for
numbered information transfer, i.e. to terminate ABM and go into ADM. With the DISC command, no
information transfer is allowed.
The other RLP-entity shall answer with a UA response before actioning the DISC command. When a
DISC command is actioned, loss of information may occur. It is the responsibility of the layers above, to
provide for a "graceful" disconnect.
5.2.2.4 Disconnected Mode, DM (11000)
The DM encoding is used as a response only. It is used by RLP entity to report that it is in ADM and, as an
answer to SABM, that it is (possibly temporary) unable to action a mode setting command. With the DM
response, no information transfer is allowed.
5.2.2.5 Unnumbered Information, UI (00000)
The information field is to be interpreted as unnumbered information. Unnumbered Information (UI)
frames can be sent in both ADM and ABM. There is no acknowledgement of receipt of UI-frames
within RLP.
5.2.2.6 Exchange Identification, XID (11101)
The information field is to be interpreted as exchange identification. This frame is used to negotiate and
renegotiate parameters of RLP and layer 2 Relay function. XID frames can be sent in both ADM and ABM.
The negotiation procedure is one step i.e. one side will start the process by sending an XID command,
offering a certain set of parameters from the applicable parameter repertoire (see table 1) the sending
entity wants to negotiate proposing values within the allowed range. In return, the other side will send an
XID response, either confirming these parameter values by returning the requested values, or offering
higher or lower ones in their place (see table 1 for sense of negotiation), except when the indicated RLP
version is a lower one where a limited set of those parameters presented in the XID command may be

Page 14
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
answered according to the negotiated version. In RLP versions higher than "0", any unrecognisable
parameters will be ignored. Default values will apply to those parameters which are not commented upon
by the responding side (see section 5.4 for default values). This normally will end the negotiation process.
XID frames are always used with the P/F-bit set to "1".
Without any prior XID exchange, default values will apply (see section 5.4). A negotiation of data
compression parameters (see table 1) is only allowed in ADM. In addition, in RLP version 2, negotiation of
RLP version N°(see table1) is only allowed in ADM.
In the case of a collision of XID commands, all XID commands shall be ignored. The MS shall restart the
parameter negotiation on expiry of T1, while the Interworking Function shall do so on expiry of twice the
value of T1. An unsuccessful XID exchange shall be repeated on expiry of T1. After N2 times of
unsuccessful repetition, the link shall be disconnected.
In table 1 a list of parameters is given which constitute the parameter repertoire. In addition, the format of
the XID information field is given.
Table 1: XID parameters
Parameter Name Type Length Format Units Sense of Valid in
Negotiation Versions
(87654321)
*
RLP version N° 1 1 bbbbbbbb ./. down ≥ 0
IWF to MS window size 2 1 00bbbbbb ./. down 0.1
IWF to MS window size 2 1 00bbbbbb 8 down
≥ 2
MS to IWF window size 3 1 00bbbbbb ./. down 0.1
MS to IWF window size 3 1 00bbbbbb 8 down
≥ 2
Acknowledgement Timer(T1) 4 1 bbbbbbbb 10ms up
≥ 0
Retransmission attempts (N2) 5 1 bbbbbbbb ./. up ≥ 0
Reply delay (T2) ** 6 1 bbbbbbbb 10ms up
≥ 0
Compression P 7 4 aaaa ./. none
≥ 1
T
P    00bb ./. see [15]
P low cccccccc
P high cccccccc ./. down
P dddddddd ./. down
Re-sequencing timer (T4) ** 8 1 bbbbbbbb 10 ms up ≥ 2
* NOTE 1: Characters "a", "b", "c" and "d" indicate a bit which is part of the parameter value in
question. Parameters indicated by "a" are not negotiable.
** NOTE 2: In case of negotiation of this parameter it may be necessary to negotiate also the other
timer values (e.g. "Acknowledgement timer" (T1)).
The type and length are encoded within one octet, the type field occupying bits 8 to 5 and the length field
occupying bits 4 to 1; 1 resp. 5 being the least significant bit. The least significant bit shall always be
transmitted first.
A parameter item consists of the type/length-octet followed by the value of that parameter, where the
length-indicator gives the number of octets the value actually occupies. Such parameter items may be
arranged in arbitrary order, with the exception of the RLP version number, which shall be sent first in RLP
versions higher than "0". The parameter items must begin in the first octet of the XID-information field and
follow on contiguously. The parameter list is delimited by parameter type zero.
5.2.2.7 Test, TEST (00111)
The information field of that frame is to be interpreted as test information. Test frames can be sent in both
ADM and ABM. A test sequence is always initiated by sending a TEST command in one direction and
completed by sending a TEST response in the other direction.

Page 15
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
5.2.2.8 Null information, NULL (11110)
In ADM, null-frames shall be sent each time there is a send opportunity but no UI, TEST or XID frame is
awaiting transmission.
In ABM, null-frames shall be sent in reset state if there is a send opportunity and no unnumbered frames
are to be sent.
The information field is to be interpreted as null information i.e. the information field is not used and its
contents may be arbitrary.
5.2.2.9 REMAP (10001)
A REMAP-exchange can only take place in ABM when the RLP-entities are in synchronisation mode
following a change of channel coding. The exchange is started by the mobile-end which sends a REMAP
command U-frame in the information field of which the RLP-entity indicates the N(R) of the frame -
according to the ‘old’ frame format - from which the network-end should resend the information mapped
into a frame format corresponding to the new channel coding. The mobile-end sends a REMAP-frame on
every sending opportunity until a responding REMAP-frame is received from the network-end. The
network-end answers by sending a REMAP U-frame with the C/R-bit set to ‘Response’. In the information-
field the network-end indicates the N(R)-number of the frame from which the mobile-end should remap
the information into the new frame format. The network-end responds to all REMAP-commands it
receives. Any REMAP-acknowledgement that may arrive at the mobile-end after one of them has been
received is discarded by the mobile-end. The RLP shall supervise the synchronisation state by a timer with
the value of N2*T1. If the network-end does not receive an appropriate U-frame within N2*T1, it enters. If
the mobile-end does not receive a response within N2×T1 measured from the transmission of the first
command, it enters ADM.
In addition to the N(R)-information the REMAP-frame information field can include any XID-parameters
that should be renegotiated because of the change of channel coding. The procedures concerning these
XID-parameters are as defined in section 5.2.2.6 (Exchange Identification) except that the mobile-end
always starts the negotiation. Also the mapping of the parameters is as defined in section 5.2.2.6
(Exchange Identification) except that the first two octets in the REMAP information field are occupied by
the N(R)-number (The LSB is transmitted first). If no XID-parameters are included in the REMAP-
information field, the values used before the change of channel coding remain valid. The information field
must, however, always include parameter type zero, which delimits the XID-parameter list.
Header 16 bits N(R) 9 bits xxxxxxx XID parameters 00000000 xxxxxx FCS 24 bits
Information field either 200 or 536 bits x= don’t care
Figure 3: REMAP U-frame format
5.2.3 Supervisory frames, S, and numbered information transfer and supervisory frames
combined, I+S
In ABM, there are cases where there is no user information pending transmission. In consequence,
supervisory (S) frames alone must be conveyed. In such cases, the information field is to be interpreted
as null information, i.e. the information field is not used and may be of arbitrary contents.
For reasons of optimization in the special situation of digital radio transmission, numbered information
transfer frames carry also supervisory type information ("piggy-backing"). Numbered information can be
exchanged only in ABM.
NOTE: The extent to which piggy-backing is used by the sending RLP entity is optional. An
RLP entity receiving any of allowed piggy-backed formats, however, shall take the
appropriate actions. Implementors should be aware that not using the full capability of
piggy-backing could, in certain circumstances, result in a less than optimal
performance.
Page 16
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
5.2.3.1 Numbering
Each I frame is sequencially numbered and may have the value 0 through M-1, where M is the modulus.
The modulus M is 62 (single-link) or 496 (multi-link).
5.2.3.2 Send Sequence number, N(S)
The send sequence number contains the number of the I frame. With the exception of SREJ conditions,
information frames are transmitted in numerical order of their N(S). If multiple physical links are used, the
frames may arrive the receiver in another order. Normal information transfer is halted, when the number of
outstanding, unacknowledged frames is equal to the currently established window size (see section 5.4).
5.2.3.3 Receive sequence number, N(R)
The N(R) field is used in ABM to designate the next information frame to be sent by the other RLP entity
and to confirm that all frames up to and including N(R) - 1 have been received properly. As an exception
to this, in the case of SREJ (selective reject), N(R) designates the information frame that is selectively
rejected and thus requested for retransmission. In this case, no previously received frames are confirmed.
5.2.3.4 L2R Status bit
The L2R status bit set to „1“ indicates that the L2R PDU transported in the information field of the RLP
PDU contains at least a status octet. Otherwise, the L2R PDU contains only user data. The bit is only used
for RLP-version 2.
5.2.3.5 Receive ready, RR (00)
The RR encoding can be used either as command or response. In ABM, it is used by an RLP entity to
confirm all information frames up to and including N(R)-1. In doing so, the RLP-station allows the other
station to transmit up to k additional information frames, counting from N(R) onwards. The issue of an RR
command/response clears any previous busy condition in that direction.
5.2.3.6 Reject, REJ (01)
The REJ encoding can be used either as command or response. It is used by an RLP entity to indicate
that in numbered information transfer one or more out-of sequence frames have been received. Frames
up to and including N(R)-1 have been received correctly, frames N(R) and following are requested to be
retransmitted. Following retransmission of those frames, further frames awaiting initial transmission may
be sent. With respect to each direction of transmission, only one REJ condition may exist at any given
time.
Page 17
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
A REJ condition is cleared:
- on receipt of the frame numbered N(R);
- on time-out;
- or on reset (SABM).
An REJ shall be sent at the earliest opportunity. On time-out, REJ frames shall not be repeated. An
RLP-entity receiving an REJ frame with the same N(R), which has already been the starting frame of a
retransmission sequence due to P/F-bit checkpointing, shall inhibit the retransmission due to that
particular REJ frame.
5.2.3.7 Receive not ready, RNR (10)
The RNR encoding can be used either as command or response. It is used by an RLP entity to indicate
that it is temporarily not ready to receive numbered information frames. In that case, the RLP entity is said
to be in the busy condition. All frames up to and including N(R)-1 shall be considered acknowledged.
Subsequent frames, if any, shall not be considered confirmed. The acceptance status of those is a matter
of further status exchange.
5.2.3.8 Selective reject, SREJ (11)
The SREJ encoding can be used either as command or response. The SREJ command/response is used
to request retransmission of a single frame, thus, under certain circumstances, providing for more efficient
error recovery than by REJ. No acknowledgement of received I frames is indicated by an SREJ frame,
thus allowing an RLP entity to transmit one or more SREJ frames with a different N(R) before earlier
SREJ conditions have been cleared.
An SREJ condition shall be cleared:
- on receipt of an information frme with N(S) equal N(R) of the SREJ;
- on time out;
- on reset (SABM).
No SREJ shall be issued during a pending REJ condition. For each frame, only one SREJ condition may
exist at any time.
SREJ frames shall be sent at the earliest possibility. On time-out, SREJ frames may be repeated.
NOTE: Sending SREJ commands/responses is not mandatory.
5.3 Error Recovery
5.3.1 Improper frames
Frames containing an FCS error or having a control field the contents of which is not implemented or
inconsistent with those defined in this Specification are called improper frames. Improper frames shall be
ignored, i.e. the receiving RLP station shall not make any use of their contents.
5.3.2 N(S) sequence error
In numbered information transfer, any information frame with an N(S) out of the normal sequence shall
lead to an N(S) sequence error condition, unless that frame is requested for retransmission by an SREJ,
sent at an earlier time. In case multiple channels make up a connection when the of a multi-link version is
used the received frames must be re-sequenced. For that a timer T4 defines a re-sequencing period (see
section 5.4) during which frames may be out-of-order. An N(S) sequence error condition only occurs if the
N(S) arrives after the expiry of T4. There are three mechanisms to deal with N(S) sequence errors:
- REJ recovery;
- SREJ recovery;
- P/F-bit recovery (checkpointing);

Page 18
ETS 300 946 (GSM 04.22 version 5.2.1): January 1998
the first two being the responsibility of the receiving station, the last being the responsibility of the sending
station. There are no strict rules as to whether REJ or SREJ recovery shall be applied, however, if a
station decides to initiate REJ or SREJ recovery, i
...