6 Service definitions

04.223GPPTS

6.1 Introduction

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.

L2R SL

user

RLP Service

RLP


RLP SL

provider

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.

6.2 Conventions

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:

a) connect;

b) connection-mode data (numbered information);

c) reset;

d) disconnect.

The following objects may be placed in a queue by a service provider:

a) reset;

b) synchronization mark;

c) disconnect.

NOTE: Other possible objects (i.e. unnumbered information, identification, test) are irrelevant (-) to the queue model and for reasons of simplicity are not shown.

Following

Connect

Data

Reset

Sync Mark

Disconnect

Preceding

Connect

NA

‑‑‑‑

‑‑‑‑‑

NA

DES

Data

NA

‑‑‑‑

DES

NA

DES

Reset

NA

‑‑‑‑

DES

‑‑‑‑

DES

Synchronization Mark

NA

‑‑‑‑

DES

NA

DES

Disconnect

NA

NA

NA

NA

DES

Legend:

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

Link establishment

RLP-CONNECT-REQUEST

RLP-CONNECT-INDICATION

RLP-CONNECT-RESPONSE (-NEG)

RLP-CONNECT-CONFIRM (-NEG)

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.

Reset

RLP-RESET-REQUEST

RLP-RESET-INDICATION

RLP-RESET-RESPONSE

RLP-RESET-CONFIRM

Release

RLP-DISCONNECT-REQUEST

RLP-DISCONNECT-INDICATION

Miscellaneous

unnumbered information

RLP-UNITDATA-REQUEST (INF)

RLP-UNITDATA-INDICATION (INF)

Exchange Identification

RLP-XIDDATA-REQUEST (INF)

RLP-XIDDATA-INDICATION (INF)

Test

RLP-TESTDATA-REQUEST (INF)

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.