This chapter defines the service provided by the RLP-sublayer to the L2R-sublayer at the boundary between the RLP-sublayer and the L2R-sublayer.
The relationships between RLP-sublayer, L2R-sublayer and RLP-protocol are shown in figure 3.
Figure 4: Basic relationship between RLP and L2R
The RLP service is defined in terms of:
– the primitive actions and events of the service;
– the parameters associated with each primitive action and event;
– the inter-relationship between, and the valid sequence of, these actions and events.
For the description of the Data Link Service, the following conventions are used with time-sequence diagrams:
Figure 5: Confirmed service with acknowledgement
Figure 6: Unconfirmed service
In time-sequence diagrams, time moves from top to bottom. Arrows indicate the flow of information. Such flow of information may be subject to implicit flow-control. Skewed lines indicate a logical relationship between arrows. For clarity, the absence of such a relation may be marked by the symbol "~" (tilde).
6.3 Queue model
Between the two endpoints of an RLP-connection, there exists a flow control function. As a means of specifying this flow control feature and its relationship with other capabilities of the RLP, the following queue model is provided.
Figure 7: Queue Model
The following objects may be placed in a queue by a service user:
b) connection-mode data (numbered information);
The following objects may be placed in a queue by a service provider:
b) synchronization mark;
NOTE: Other possible objects (i.e. unnumbered information, identification, test) are irrelevant (-) to the queue model and for reasons of simplicity are not shown.
NA : Not applicable
‑‑ : not destructive, not able to advance ahead of the preceding object
DES : Destructive to the preceding object
6.4 List of Primitives
Normal Data Transfer
RLP-DATA-REQUEST (S, INF)
RLP-DATA-INDICATION (S, INF)
NOTE: The parameter S (L2R status bit) is only relevant for RLP-version 2.
RLP-TESTDATA-CONFIRM (-NEG) (INF)
6.5 Possible RLP time sequence diagrams
a) Connection establishment (without collision)
b) Connection establishment (with collision)
c) User invoked release (without collision)
d) Collision of user invoked releases
e) Simultaneous user and provider invoked release
f) Provider invoked release
g) Provider rejection of establishment
h) Normal data transfer
I) User invoked reset
j) Collision of user invoked resets
k) provider invoked reset
l) simultaneous user and provider invoked reset
Figure 8: State transition diagram for sequence of RLP connection-mode service primitives
Annex A (informative): RLP SDL Diagrams
This annex describes a model implementation of an RLP entity for RLP version "0".
The description should help to clarify GSM Specification 04.22, the RLP service and protocol definition.
However, it is not intended to restrict any implementation of an RLP entity in any way, on condition the implementation shows the correct behaviour at the RLP protocol level.
The model implementation consists of three processes. Process "SEND_PDU" adds the CRC to a given PDU and hands it to the lower layer entity for transmission. Process "RECEIVE_PDU" gets a received PDU block, checks the value of the CRC and the bits of the PDU header. If the CRC has the right value and if the header is syntactically correct, the receipt event is signalled to the "RLP_KERNEL" process, which is the protocol handling automaton.
Each process is described as an extended finite state machine (using SDL-Diagrams).
Each state of the automaton is described by a (main-)state number and a corresponding (main-)state name. The state may further be distinguished by the value of other state variables. This scheme is used because not every state variable needs to be defined in every state. The states are defined in chapter A.1.
The RLP machine reacts on events, which may be classified as:
– lower layer interface events;
– upper layer interface events; and
– station management or internal events.
The events of the RLP-Kernel are described in section A.2.