6 Service definitions

24.0223GPPRadio Link Protocol (RLP) for circuit switched bearer and teleservicesRelease 17TS

6.1 Introduction

This subclause 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 4.

	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 the present document, 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 clause 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 clause A.2.