8 X.25 Based Services

07.603GPPGeneral Packet Radio Service (GPRS)Mobile Station (MS) supporting GPRSTS

This clause describes the use of X.25 based services over the GPRS bearer. Two services are specified at the R reference point –

1) Character mode (specified in ITU-T X.3, X.28, X.29) with the triple X PAD in the MT.

2) Packet mode (specified in ITU-T X.25).

NOTE: In order to maintain consistency within GSM specifications, the term TE is used when referring to what CCITT/ITU-T X.25 calls a DTE. Exceptionally, in text quoted from an ITU-T Recommendation, the term DTE is retained.

8.1 X.25 Character mode (triple X PAD) service

This mode is an asynchronous character based service allowing the application to set up a single connection using the CCITT/ITU-T X.28 / X.29 procedures. This supports both mobile originate and mobile terminate calls. The MT terminates the X.25 packet layer and provides a triple X PAD function.

Figure 3: Character (Triple X PAD) mode

8.1.1 PAD Parameters

The following table lists the minimum set of X.3 parameters that shall be implemented. A full range is specified in the CCITT/ITU-T X series documents and those parameters not implemented shall be fixed to their defined defaults.

Table 1: Table of Minimum X.3 Parameters

Parameter
Number

Description

Default

Value

Valid Values

Value/Function

1

PAD Recall Character

1

0

1

32-36

(None)

DLE

Binary representation of decimal value

2

Echo

0

0

1

Off

On

3

Data Forwarding Character

2

0

1

2

4

8

16

32

64

(on 128th data byte)

A-Z, a-z, 0-9

CR

ESC, BEL, ENQ, ACK

DEL, CAN, DC2

ETX, EOT

HT, LF, VT, FF

All characters between NUL & US not listed above

4

Delay Timer

0

0

1-255

Disabled

Period of TXD cct inactivity before data forwarded (1/20 of a second). The minimum time-out is 0.5s. Any value of parameter 4 between 1 & 10 will default to 0.5s.

5

Flow Control from Pad (to DTE)

0

0

1

None

XON/XOFF

6

Service Signals

5

0

1

5

Disabled

Enabled, excluding prompt

Enabled, including prompt

7

Action on Break

8

8

PAD escapes from data transfer state

11

Data Rate

13

2

3

4

6

12

13

14

300 bps

1200 bps

600 bps

150 bps

2400 bps

4800 bps

9600 bps

Other values may be implemented as long as they conform to the CCITT/ITU-T specifications.

12

Flow Control to Pad (from DTE)

0

0

1

None

XON/OFF

13

Line Feed insertion

0

0

1

None

LF inserted after CR to DTE

15

Character Deletion

0

0

1

Disabled

Enabled

Although not CCITT/ITU-T defined, to be able to specify either X.28 or X.29 modes a Parameter 0 can be used as follows.

For X.28 mode parameter 0 shall be set to 0.

For the four X.29 variants available, each with a corresponding protocol identifier, the parameter value is set as listed below. The identifier octet is supplied with the call request packet when setting up a call.

Value

Description

Protocol Identifier Octet

2

CCITT use

00000001

3

National use

01xxxxxx

4

International User Bodies

10xxxxxx

5

DTE – DTE use

11xxxxxx

x – this digit may be represented by either a 1 or 0 (to be specified in ITU-T Recommendation X.244).

8.1.2 Example mapping of functions between the R reference point and the GPRS bearer

The following example illustrates the case when the PAD functionality is used in the MT. In PAD mode only one PDP context can be activated per R reference point.

NOTE: The 2 ended arrows indicate an exchange of 0 or more messages.

Figure 4: PAD Service

1) The TE issues an AT command to activate PAD mode.

2) If the MS is not yet GPRS attached, the MT performs the GPRS Attach procedure as described in GSM 03.60.

3) The MT performs the PDP Context Activation as described in GSM 03.60.

4) The MT sends an AT response to the TE. Following a positive AT response the PAD prompt is issued.

8.2 X.25 Packet mode service

This mode offers a packet based service allowing the application to set up one or more virtual calls using the CCITT/ITU-T X.25 procedures. The maximum permitted number of concurrent virtual calls is implementation dependent. Both mobile originate and mobile terminate calls are supported. The MT performs a relay function for X.25 layer 3 which is terminated in the TE. The layer 2 protocol at the R reference point is terminated in the TE and the MT.

Depending on the application, the TE may or may not incorporate a triple X PAD function.

NOTE: The "other L2" could be GSM 07.10 or a manufacturer’s defined layer 2

Figure 5: Packet mode

8.2.1 Layer 1 and Layer 2 options

This subclause describes standardized layers 1 and 2 which may be used for the TE-MT interface. As an alternative, the multiplexing protocol specified in GSM 07.10 or a manufacturer’s defined layers 1 and 2 may be used providing they meet the requirements for carrying X.25 layer 3 frames over the R reference point.

8.2.1.1 Synchronous serial interface

For TEs with a synchronous serial port –

Layer 1 is synchronous X.21 or X.21bis (V.24/V.28).

Layer 2 is LAP B (X.25 L2) based on bit-oriented HDLC.

NOTE: Configuration of the MT in this case is outside the scope of this specification.

8.2.1.2 Asynchronous serial interface

For TEs with an asynchronous serial port –

Layer 1 is asynchronous V.24/V.28.

Layer 2 is LAP B (X.25 L2) based on character-oriented HDLC.

NOTE: The methods described in ITU-T Rec. V.80 may be applicable here.

8.2.1.3 Synchronous and asynchronous (dual mode) interface

For TEs with a serial port that can operate in both synchronous and asynchronous modes the following mechanism may be used where the interface supports AT commands. The interface starts in asynchronous mode and AT commands may be used to configure the MT. When configuration is complete, the interface switches to synchronous mode and X.25 starts up in the usual way. Setting Data Terminal Ready (circuit 108/2) to off is a protocol independent way of returning to asynchronous mode. Alternatively, the closing down of LAP B could be used as the signal.

8.2.2 Example mappings of functions between the R reference point and the GPRS bearer

The minimum requirement is that the MT shall be GPRS-attached and the X.25 context activated whilst an X.25 virtual call is in progress. Any extension to this requirement depends on whether the MT implements any other GPRS-supported services (e.g. SMS) which might require that the MT remains GPRS-attached even when there is no X.25 virtual call in progress.

The following subclauses describe only the X.25 requirements. These actions may be filtered by the requirements of any other GPRS-supported service. For example, if a GPRS-only MT also supports SMS, a request for ‘disconnection’ of the X.25 service would result in a deactivation of the X.25 context but not a GPRS-detach.

8.2.2.1 Standardized X.25 TE

This case applies to TEs which implement only the X.25 procedures, i.e. they have no support for AT commands. The layer 1 and 2 options described in subclause 8.2.1.1 and 8.2.1.2 apply.

Because of the different implementations of X.25 procedures in existing DTEs, attach/detach and activate/deactivate may need to be controlled at layer 1, 2 or 3 of the X.25 interface. Whilst it is always possible to use layer 3 control, this requires the most complete implementation of the X.25 protocol stack in the MT. Control at a lower layer may result in a simpler implementation. The procedures for connection and disconnection at all three layers are described in CCITT/ITU-T X.25.

In all cases it may be desirable to incorporate a timer to delay the deactivate/detach procedures in order to avoid excessive changes of the activation and attachment states in the course of a number of consecutive calls.

NOTE: The activation and deactivation of an X.25 context to carry packets over GPRS is analogous to setting up and clearing a switched ISDN B channel connection to carry them over an ISDN. The call control mapping procedures used in the ISDN case are described in detail in ITU-T X.31 clause 7.3 (layer 1) and appendix I (layers 2 and 3).

8.2.2.1.1 Layer 1 control

This applies to X.25 DTEs which disconnect at the physical layer when no virtual calls are in progress. The TE and MT signal to one another by using V.24 or X.21 control signals.

From TE –

Physical layer connect received by MT -> attach, activate

Physical layer disconnect received by MT -> deactivate, detach

From network –

If the X.25 context is not currently active, an attempt by the network to offer a mobile terminated X.25 virtual call will be signalled by the receipt at the MT of a Request PDP Context Activation message. The MT signals this to the TE by using V.24 or X.21 control signalling and, if successful, -> attach, activate.

A network request that the X.25 context should be deactivated or a failure of the radio link will result in the MT performing a physical layer disconnect.

8.2.2.1.2 Layer 2 control

This applies to X.25 DTEs which keep layer 1 active but disconnect at the data link layer when no virtual calls are in progress. The TE and MT signal to one another by starting and stopping the data link layer protocol.

From TE –

Data link layer set-up received by MT -> attach, activate

Data link layer disconnect received by MT -> deactivate, detach

From network –

If the X.25 context is not currently active, an attempt by the network to offer a mobile terminated X.25 virtual call will be signalled by the receipt at the MT of a Request PDP Context Activation message. The MT signals this to the TE by attempting to start the data link layer and, if successful, -> attach, activate.

A network request that the X.25 context should be deactivated or a failure of the radio link will result in the MT performing a data link layer disconnect.

8.2.2.1.3 Layer 3 control

This applies to X.25 DTEs which keep layers 1 and 2 active when no virtual calls are in progress.

From TE –

Call Request packet received by the MT -> attach, activate
(Action is taken only if there are no X.25 virtual calls already in progress)

Clear Confirmation packet received by the MT from the TE -> deactivate, detach
(Action is taken only if there are no more X.25 virtual calls in progress.)

From network –

If the X.25 context is not currently active, an attempt by the network to offer a mobile terminated X.25 virtual call will be signalled by the receipt at the MT of a Request PDP Context Activation message. Following activation by the MT, an X.25 Call Request packet will be received from the network.

Clear Confirmation packet received by the MT from the network -> deactivate, detach
(Action is taken only if there are no more X.25 virtual calls in progress.)

A network request that the X.25 context should be deactivated or a failure of the radio link will result in the MT clearing any outstanding X.25 virtual calls.

The above refer only to normal clearing situations. An actual implementation shall take into account exceptional conditions such as the receipt of a Clear Request packet from the TE but no acknowledging Clear Confirmation from the network.

8.2.2.2 X.25 TE with support for AT commands

This case applies to TEs which implement AT commands in addition to supporting X.25 procedures. The layer 1 and 2 options described in subclauses 8.2.1.2 and 8.2.1.3 apply.

The TE sends GPRS AT commands to configure the MT, followed by a command to switch the interface into packet mode and start X.25. A mode of operation may be supported which provides compatibility with existing modem dial procedures.