5 Elements and procedure
24.0223GPPRadio Link Protocol (RLP) for circuit switched bearer and teleservicesRelease 17TS
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.
5.2.1 Generally used bits
NOTE 1: C/R = COMMAND/RESPONSE BIT
P/F = POLL/FINAL BIT
X = DON’T CARES
M1M2M3M4M5 |
|||||
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 |
||||
S1 |
S2 |
1 1 0 0 0 |
D M |
||
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:
NOTE 2: 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 |
0 |
1 |
1 |
1 |
1 |
1 |
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 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
Version 2:
NOTE 3: S = L2R Status Bit
N(S) : Bit 1 low order bit
N(R) : Bit 14 low order bit
UP : UP bit (only if negotiated, ‘don’t care’ otherwise)
U |
C/R |
X |
X |
1 |
1 |
1 |
1 |
1 |
1 |
P/F |
M1 |
M2 |
M3 |
M4 |
M5 |
X |
||||||||
S |
X |
X |
X |
0 |
1 |
1 |
1 |
1 |
1 |
P/F |
C/R |
S1 |
S2 |
______________ N(R) ______________ |
X |
UP |
||||||||
I+S |
______________ N(S) ______________ |
P/F |
C/R |
S1 |
S2 |
______________ N(R) ______________ |
S |
UP |
||||||||||||||||
bit |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
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.
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. In version 2, the UA response is sent no sooner than T4 (see subclause 5.5.6) after the last information frame sent. Information frames received within a period of T4 after reception of the SABM are discarded.
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 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 subclause 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 subclause 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 table 1) is only allowed in ADM.
In the case of a collision of XID commands, all XID commands shall be ignored. The UE 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 (87654321) |
Units |
Sense of Negotiation |
Valid in Versions |
RLP version N° |
1 |
1 |
bbbbbbbb (note 1) |
./. |
down |
0 |
IWF to UE window size |
2 |
1 |
00bbbbbb |
./. |
down |
0..1 |
IWF to UE window size |
2 |
1 |
00bbbbbb |
8 |
down |
2 |
UE to IWF window size |
3 |
1 |
00bbbbbb |
./. |
down |
0..1 |
UE 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) (note 2) |
6 |
1 |
bbbbbbbb |
10ms |
up |
0 |
Compression PT P0 P1 low P1 high P2 |
7 |
4 |
aaaa 00bb cccccccc cccccccc dddddddd |
./. ./. ./. ./. |
none see ITU-T Q.921 [15] down down |
1 |
Re-sequencing timer (T4) (note 2) |
8 |
1 |
bbbbbbbb |
10 ms |
up |
2 |
Optional features |
9 |
1 |
bbbbbbbb |
./. |
down |
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.
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 following a change of channel coding. REMAP frames are always used with the P/F-bit set to "0". 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 as long as it is in the REMAP synchronisation state. The network sends a numbered S frame with poll bit P=1 or an I+S frame after the first REMAP frame to the user equipment to compel it to acknowledge the end of the REMAP condition. This frame is guarded by T1. Upon reception of an I+S frame or an S frame with the final bit F=1 from the UE, the IWF exists the REMAP synchronisation state. 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 ADM. If the mobile-end does not receive a response within N2T1 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 subclause 5.2.2.6 except that the mobile-end always starts the negotiation. Also the mapping of the parameters is as defined in subclause 5.2.2.6 except that the first two octets in the REMAP information field are occupied by the N(R)-number (The LSB is transmitted first). The information field shall always include parameter type zero, which delimits the XID-parameter list.
After the change of channel coding, default values according to the new channel coding apply until new values have been negotiated by the REMAP or XID procedure. Default values according to the new channel coding also apply for those XID parameters that are not included in the REMAP information field. Values for XID parameters whose negotiation is only allowed in ADM remain valid after change of channel coding.
Header 16 bits |
N(R) 6 bits |
xxxxxxxxxx |
XID parameters |
00000000 |
xxxxxx |
FCS 24 bits |
Information field either 200 or 536 bits x= don’t care |
||||||
< > |
a) version 0 and 1
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 |
||||||
< > |
b) version 2
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. Implementers should be aware that not using the full capability of piggy-backing could, in certain circumstances, result in a less than optimal performance.
5.2.3.1 Numbering
Each I frame is sequentially 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 substreams are used, the frames may arrive at 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 subclause 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.
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 frame 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.2.3.9 Upgrading Proposal bit, UP bit
In version 2, the UP bit in the S and I+S frame headers may be used by the IWF to indicate to the UE that a service level upgrading will increase the throughput, and is used in accordance with 3GPP TS 27.001 [9] and 3GPP TS 29.007 [13]. The usage of the UP bit is negotiated by XID exchange.
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 the present document 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 substreams make up a connection when the multi-link version is used the received frames must be re‑sequenced. For that a timer T4 defines a re-sequencing period (see subclause 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).
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, it shall do so at the earliest opportunity. The information part of out-of sequence frames shall be discarded, unless the receiving station intends to initiate SREJ recovery.
5.3.3 N(R) error
Any confirming N(R) that is not in the range of the window size shall be ignored.
5.3.4 Time-out and checkpointing
All frames requiring a response or acknowledgement shall be guarded by time-out (timer T1). In detail, those frames are:
– SABM;
– DISC;
– REJ;
– SREJ;
– numbered information frames (see note);
– any frame with the P-bit set to "1" in ABM, i.e. checkpointing.
NOTE: T1 started, or restarted if already running, on the transmission of every numbered information frame.
5.3.4.1 Treatment of errors during link establishment, link reset and link disconnect
An SABM, which is not answered by either UA or DM within the timer period, shall be repeated up to N2 times.
A DISC, which is not answered by UA within the timer period, shall be repeated up to N2 times.
If the SABM or DISC, respectively, is finally unanswered, the RLP station will go into ADM in any case. For this reason, it is the responsibility of the management of any RLP entity to put the RLP entity into ADM, should there be an indication of a permanent outage, i.e. a loss of connectivity longer than N2 times the timer value.
5.3.4.2 Treatment of errors during numbered information transfer
The last frame of a sequence of numbered information frames shall also be guarded by time-out. If neither a positive acknowledgement nor a REJ is received, the RLP entity will start checkpoint recovery, i.e. the station will send a frame with the P-bit set to "1", requesting the latest status information from the other entity, indicated by the F-bit set to "1". In that case, status information is carried either by RR or RNR responses and all frames currently held by the responding RLP entity which are not delivered because of missing frames shall be discarded. A P-bit set to "1" shall only be sent with a Supervisory Frame.
Awaiting the latest status information from the other RLP entity, the sending entity does not react on REJ and SREJ frames received during this time. If such status information is received, retransmission from N(R) onwards will be performed if appropriate. However, no frame sequence starting with a given N(R) shall be retransmitted more than N2 times. If there is a frame sequence that cannot be transmitted successfully after N2 repetitions, the RLP link shall be reset or disconnected.
If no status information is received during the time-out period, this request will be repeated up to N2 times. If still there is no valid status reported back, the RLP link shall be reset or disconnected.
5.3.5 Contentious situations
Due to the asynchronous procedure, various contentious situations may arise. A contention of SABMs shall result into both entities be set into ABM or be reset. A contention of DISC’s shall result into both entities be disconnected. A contention of SABM and DISC shall result into both entities be disconnected.
5.4 Transitions between 240 bit and 576 bit frame lengths
The RLP has to change the supported frame length due to transitions between different channel codings. The RLP entities have to be re-synchronised after a change of the channel coding.
Any change of the channel coding is indicated to the RLP- entity by an external event. The RLP-entity at the mobile‑end enters the synchronisation state when it receives a relevant Radio Resource Management message, and it starts sending the REMAP-messages at the earliest possible time. The RLP-entity at the network-end enters the synchronisation state when the network-end detects Layer 1 synchronisation after a change of channel coding. The change of channel coding is eventually confirmed by an outband signalling message.
On entering the synchronisation state timers are halted and zeroed, and the TX- and RX-windows are frozen. When the RLP entity enters the synchronisation state it clears all SREJ or REJ conditions, discards all out-of-sequence frames received and clears all previous re-transmission requests received by any SREJ.
After this the mobile-end starts a REMAP-exchange (subclause 5.2.2.9). When an RLP-entity receives a REMAP‑frame, it moves the user information contained by the frames to be remapped from the TX-window to a transition buffer between the RLP- and L2R-entities. The L2R uses the information in this buffer before mapping new data into the PDUs. The network-end regards the REMAP-procedure as completed when it has received an I+S-frame, an S-frame or an SABM U-frame from the mobile-end, whereas the mobile-end leaves the synchronisation state after receiving a responding REMAP-frame or an SABM U-frame. The data in the transition buffer at the network-end must not be deleted before an I+S-, or an S-frame is received from the mobile-end.
Supervisory or Information transfer frames or XID U frames are discarded by the receiving entity while in REMAP synchronisation state. If the RLP entity receives another U-frame, it reacts according to the defined procedures. That is, if the frame is an SABM frame it performs a reset procedure and leaves the synchronisation state. If the frame is NULL, UI or TEST frame, RLP performs the defined procedure and remains in the synchronisation state. In the case of a DISC frame RLP terminates ABM and goes into ADM.
After the REMAP-procedure is completed, the RLP-entities leave the synchronisation state and normal operation is resumed. On resuming the normal operation, the TX- and RX- windows are emptied. The N(S)-numbering resumes from the value indicated in the REMAP-message by the N(R)-number.
Abortion of the transition or another transition taking place during the REMAP-procedure restarts the REMAP‑procedure in order to resume operation using the channel coding corresponding to the latest transition.
5.5 List of system parameters
The system parameters are as follows.
Table 2: RLP parameter values
Name |
Range of values |
Default value |
Recommended value |
Version N° |
0 – 2 |
0 |
2 |
k UE IWF (for N° = 0/1) |
0 – 61 |
61 |
61 |
k UE IWF (for N° = 2) |
0 – kmax (note 3) |
480 |
240 (note 2) |
k IWF UE (for N° = 0/1) |
0 – 61 |
61 |
61 |
k IWF UE (for N° = 2) |
0 – kmax (note 3) |
480 |
240 (note 2) |
T1 (note 1) |
> 420 ms (version2) > 380 ms > 440 ms |
520 ms (fullrate on 14, 5 kbit/s, 29,0 kbit/s or 43,5 kbit/s) 480 ms (fullrate on 12 kbit/s) 540 ms (fullrate on 6 kbit/s) |
520 ms (fullrate on 14, 5 kbit/s, 29,0 kbit/s or 43,5 kbit/s) 480 ms (fullrate on 12 kbit/s) 540 ms (fullrate on 6 kbit/s) |
T2 (note 1) |
< 80 ms (fullrate on 14,5 kbit/s, 29,0 kbit/s or 43,5 kbit/s) < 80 ms (fullrate on 12 kbit/s) < 80 ms (fullrate on 6 kbit/s) < 80 ms (halfrate) |
< 80 ms (fullrate on 14,5 kbit/s, 29,0 kbit/s or 43,5 kbit/s) < 80 ms (fullrate on 12 kbit/s) < 80 ms (fullrate on 6 kbit/s) < 80 ms (halfrate) |
|
N2 |
> 0 |
6 |
6 |
PT |
0 |
0 |
0 |
P0 |
0 – 3 |
0 |
3 |
P1 |
512 – 65535 |
512 |
2048 |
P2 |
6 – 250 |
6 |
20 |
T4 (note 1) |
> 25 ms |
30 ms 50 ms (fullrate on 14,5 kbit/s, 29,0 kbit/s or 43,5 kbit/s) |
30 ms 50 ms (fullrate on 14,5 kbit/s, 29,0 kbit/s or 43,5 kbit/s) |
Optional feature, Up signalling |
0 – 1 |
0 |
1 |
NOTE 1: The timer values shall fulfil the formula: NOTE 2: This value is recommended in the case of 4 physical links. NOTE 3: The maximum window size shall fulfil the formula: |
5.5.1 RLP Version N°
The current version of RLP is "2". "0" is the default value for the version N°. RLP-versions are backwards compatible. It is assumed that future versions of RLP will be backwards-compatible with former ones. Backwards-compatible refers to the signalling, i.e. the handling of the parameters in the XID frame. The parameters are defined as specified by the RLP version with the lower number.
5.5.2 Maximum number of outstanding I frames k (Window size)
The window size is the maximum number (k) of sequentially numbered I frames that may be outstanding (i.e. unacknowledged) at any given time. It shall be agreed for a period of time.
In case of a single-link version the value can never exceed 61. In the case of a multi-link version it is necessary to use a window size that is less than the sequence number space to avoid misinterpretations of the confirming N(R). Therefore, a guard section is defined and the value k must not exceed the value kmax defined in table 2. On mutual agreement between the communication parties, a smaller window size may be established. For the support of 4 physical links, a value of 240 is recommended.
5.5.3 Timer T1
The period of Timer T1 is regarded to start at the beginning of the transmission of the relevant frame.
The negotiation (or default) value is defined to be the earliest instant to enter recovery.
The period of Timer T1 at the end of which retransmission of a frame may be initiated according to the procedures described in subclause 5.3, is a system parameter agreed for a period of time.
The proper operation of the procedure requires that Timer T1 be greater than the maximum time between transmission of frames (SABM, DM, DISC, I or supervisory commands) and the reception of the corresponding frame returned as a response to this frame (UA, DM or acknowledging frame). Therefore, the RLP entity should not delay the response or acknowledging frame returned to the above frame by more than a value T2. T2 is a system parameter, which is less than T1. T1 is influenced by the value of T4 and shall fulfil the formula in table 2.
5.5.4 Maximum number of retransmissions N2
The value of the maximum number of retransmissions N2 of a frame following the running out of Timer T1 is a system parameter agreed for a period of time.
5.5.5 Data Compression Parameters
If the Layer 2 Relay function supports a data compression function and its use is desired the needed data compression parameters have to be negotiated. The parameter PT is not negotiable. In case of V.42 bis the parameters P0, P1 and P2 have to be negotiated. The parameters are defined as follows:
– PT: Type of data compression:
– 0 V.42 bis;
– other values are reserved.
– P0: V.42bis data compression request:
– 0 compress in neither direction;
– 1 compress in initiator-responder direction only;
– 2 compress in responder-initiator direction only;
– 3 compress in both directions.
– P1: V.42bis number of possible codewords in the algorithm;
– P2: V.42bis maximum encodable data string length.
The initiator is the sender of XID command, the responder is the sender of XID response.
5.5.6 Re-sequencing period (Timer T4)
In the case of a multi-link version frames may be received out of sequence due to different transmission delays. The period of timer T4 guards the re-sequencing period. During this time frames may be out of sequence.
T4 is a system parameter agreed for a period of time. The proper operation of the procedure requires that the timer T4 shall be greater than the re-sequencing period and it shall fulfil the formula in table 2. A change of the timer T4 has impact on the usable maximum window size as defined in table 2.
5.5.7 Optional features
The format of the optional features parameters is an octet where each bit position represents an optional feature that can be negotiated. The optional features are:
Bit position |
Optional feature name |
1 |
Up signalling |
2 |
(Not yet assigned) |
3 |
(Not yet assigned) |
4 |
(Not yet assigned) |
5 |
(Not yet assigned) |
6 |
(Not yet assigned) |
7 |
(Not yet assigned) |
8 |
(Not yet assigned) |
The ‘Optional Features’ parameter is negotiated bitwise in the downward sense, meaning that the value of bit i in the XID response shall be less or equal to the value of bit i in the XID command.
Up signalling: If the negotiated value of the ‘Up signalling’ feature is 1, then the UP bit in the S and I+S frame header is used for indicating an upgrading proposal to the UE, otherwise the UP bit is ignored (don’t care). This optional feature is only applicable for A/Gb mode and GERAN Iu mode.
5.6 Support for discontinuous transmission (DTX)
In both ADM and ABM, whenever the RLP entity has no numbered or unnumbered supervisory commands/responses and no information transfer frames pending transmission, the RLP entity shall indicate to the lower layer that the DTX function may be invoked.
5.6.1 In case of A/Gb mode
Protocol of lower layer conforms to 3GPP TS 48.004 [3], 3GPP TS 48.020 [25] and 3GPP TS 44.021 [2]. A/Gb mode specification assumes STM for lower layer protocol. Even if there is no data to be sent, some transmission is needed on STM. RLP acts as follows in case of DTX.
In case DTX is invoked, in ADM a NULL-frame will be sent, and in ABM a RR or RNR S-frame will be sent.
5.6.2 In case of Iu mode
Protocol of lower layer conforms to 3GPP TS 25.410 [5], 3GPP TS 25.411 [6], 3GPP TS 25.414 [7], 3GPP TS 25.415 [8] and 3GPP TS 43.051 [29]. Iu mode specification assumes ATM for lower layer protocol. When there is no data to be sent, no transmission is available on ATM. In consideration of transmission efficiency, no transmission is suitable. RLP acts as follows in case of DTX.
In case DTX is invoked, in ADM and ABM no frame will be sent.