W1 10 Pad&related Pro

PAD & RELATED PROTOCOLS (X.3, X.28 & X.29)

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

PAD & RELATED PROTOCOLS (X.3, X.28 & X.29) 1. General In order to connect asynchronous terminals to a synchronous packet switched network, a device called PAD is required. Physically, the PAD can be a part of the public network or a private black box at the end of an X.25 access link Both the operator behind the asynchronous terminal and the application which is connected at the other end via and X.25 connection must be able to “talk” the PAD. Recommendations X.3, X.28 and X.29 define how an unintelligent start – stop terminal is used in the network. It is the software in the PAD, which performs the X.25 functions that the asynchronous terminal cannot manage by itself. In most case, an X.28 terminal calls computer which has an X.25 connection, but it is also possible for two PADs to communicate with each other. Consequently two asynchronous terminals can make contact with each other. Note, however, that the packet switched network does not allow a call to an asynchronous terminal which is connected via the public switched telephone network, PSTN (dial - up), or to a circuit switched data network (dial up connection). Two asynchronous terminals can still communicate if one of them is connected via a dedicated circuit or if a private PAD is used. Recommendation X.3 describes the parameters that the PAD uses to control the terminal. The parameter values can be preprogrammed in the PAD, altered by the terminal user or altered by the X.25 host at the other end. Recommendation X.28 describes command language between the PAD and the terminal operator. X.29

DTE-P

DCE X.25

PSN

DTE-C X.28

X.3

HOST

BRBRAITT : March-2007

PAD

[Fig 1-1] PAD Protocols

TERMINAL

2

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Recommendation X.29 describes the control messages which are sent between the PAD and the X.25 host. These message are sent in DATA packet with Q bit = 1. COMMAND MODE AND DATA TRANSFER, MODE During the time that an asynchronous terminal is physically connected that PAD, it is in one of those two modes. COMMAND MODE When the user sets up a connection to the PAD, the connection is in command mode. Here everything written on the terminal screen is interpreted as commands to the PAD, and it is not forwarded to the remote X.25 host. Certain commands can result in packet being assembled by the PAD and dispatched. CALL REQUEST and RESET are examples of such packets. DATA TRANSFER MODE All characters coming form the terminal to the PAD ARE interpreted as data which is to be forwarded. The PAD assembles packets, either when a packet is full or when a special character, such as Carriage Return, comes in. When the terminal is in data transfer mode, it cannot alter its PAD parameters without first going back to command mode. The X.25 host at the other end, however, can alter the PAD parameters during data transfer with the help of the X.29 protocol. In order to clear the data call from the asynchronous terminal, it must first go over to command mode. The X.25 host can of course also initiate cleaning. This is accomplished with the help of a special “Invitation to clear” PAD message in the X.29 protocol.

BRBRAITT : March-2007

3

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

2. PAD PARAMETERS (X.3) In the CCITT Red Book there are 22 parameters defined in Recommendation X.3 Parameter number : 1

: Escape from Data Transfer

2

: Echo

3

: Data Forwarding Signal

4

: Idle Timer

5

: Ancillary Device Control

6

: PAD Service Signals

7

: Procedure on Break

8

: Discard Output

9

: Carriage Return Padding

10 : Line Folding 11 : Terminal Speed 12 : Flow Control of the PAD by the terminal 13 : Linefeed Insertion 14 : Linefeed Padding 15 : Editing 16 : Character Delete 17 : Line Delete 18 : Line Display 19 : Editing of User Data 20 : Echo mask 21 : Parity Treatment 22 : Page Wait BRBRAITT : March-2007

4

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

DETAILED DESCRIPTION OF THE PARAMETERS Parameter 1 : Escape from Data Transfer This parameter is used to decide whether it is permitted to go over from data transfer mode to command mode from the terminal keyboard. If is it permitted, a definition is also given of the key to be used for this. If parameter 1 is set to something other 0 (i.e. it is possible to go to command mode), care must be taken that the character which is used to switch form data transfer mode to command mode is not in the text that is sent. One way of getting this character through anyway is to send it double. Suppose the character is used to switch to command mode: Example 1: SEE SAW MARGERY DAW This row will result in one being transmitted to the Other end, i.e. SEE SAW MARGERY DAW. Example 2: THIS IS AN EXAMPLE This row will, however, be split up so that THIS IS AN is sent in a data packet, and EXMPLE will be received by the PAD as a command. Setting parameter 1 to “Escape not possible” is therefore good in the case of things like file transfer to avoid the risk of breaks. By simultaneously setting parameter 7, procedure on Break to “Escape to command mode”, one press on the Break key will ensure a return to command mode anyway. Selectable possible value PAD parameter meaning Mandatory

Optional

0 1

Escape not possible 32-126

Possible using character DLE (Ctrl+P) Possible, using one graphic character Defined by user

[ Table 2-1] Par. 1 Escape from data transfer BRBRAITT : March-2007

5

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Parameter 2 : Echo With this parameter the user can decide if the PAD is to echo the characters which are sent from the asynchronous terminal. The normal function of an asynchronous terminal is to work in full duplex. To get the text on the display unit of the sending terminal, either the network (PAD) or the host has to send back the transmitted characters. If the parameter value 0 is selected and the computer at the other end sends an echo, the drawbacks this involves should be pointed out: The number of packets is doubled The function of the terminal is changed: Since packets are not usually send until after the end of a line, the line has to be finished before the text comes up on the screen again. This problem can be avoided by using a low value of the idle timer (parameter4), but then your packets will hardly ever be filled up and the cost will increase dramatically. So, for economical and functional reasons, the parameter value 1(one) is what is used most. For certain applications it might be necessary to let the computer send and echo. Examples of this might be word processing and other editing operations. It might be wise to let the application in the X.25 machine set this parameter at the right value via the X.29 protocol. Selectable possible Value PAD parameter meaning Mandatory

Optional

0

No echo from PAD

1

Echo from PAD

[Table 2-2] Par . 2 Echo

BRBRAITT : March-2007

6

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Parameter 3 : Selection of the Data Forwarding Signal This parameter tells the PAD which character or characters mean that it is time to assemble and send a packet. The PAD takes the characters in the input buffer and forms them into a packet. Notice that “Data Forwarding Signal” is the last character in every packet. Parameter value 0, “No Data Forwarding Signal”, means that a packet is sent only if it is full. Parameter value 2, “Carriage Return”, is perhaps the most common parameter values. Every time “CR” is pressed a packet is sent. The other parameter values specify more than one character. Certain combinations of parameter values are possible, namely : 2+4 2 + 16 2 + 4 + 8 + 16 + 32 + 64

Selectable Possible Value Mandatory

PAD parameter meaning

Optional

0 1 2 4 6 8 16 18 32 64 126

CR, ESC, BEL, ENQ, ACK CR, ETX, EOT CR, ESC, BEL, ENQ, ACK, DEL, CAN, DC2, ETX, EOT, HT, LF, VT, FF, + all other characters in column 0 and 1 of the IA5 alphabet.

No Data Forwarding Signal Alphanumeric characters (A-Z, a-z, 0-9) Carriage Return ESC, BEL, ENQ, ACK Combination of (2+4) DEL, CAN, DC2 ETX, EOT Combination of (2+16) HT, LF, VT, FF All other characters in column 0 and 1 Combination of (2+4+8+16+32+64) = All other character in column 0 and 1 and character DEL of ASCII alphabet

[ Table 2-3] Par. 3 Data forwarding signal BRBRAITT : March-2007

7

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Parameter 4 : Selection of Idle Timer Delay Every time the PAD receives a character from the asynchronous terminal, the Idle Timer is zeroed. If no characters come in within the timer, the PAD will form a packet from the characters in the input buffer and send it off. The Idle timer functions, in other words, as an extra “ Data Forwarding Signal”. This timer is particularly useful is parameter 3 has been set at 0, i.e. “No Data Forwarding Signal”. A parameter value of 0 means that the function is disconnected, i.e. “No Data Forwarding on Time – Out Required”. Parameter values from 1 to 255 set Time – out delay at the value times 0.05 secs. Example; Parameter value 40(DCE) gives timer delay of 40 × 0.05s = 2s. Some PADs cannot offer all of the values between 1 and 255, and in such cases the nearest value is set. Further Data Forwarding Signals A data packet can be sent for other reasons than those described by parameters 3 and 4, namely; the data packet is full a break from the terminal change over from data transfer mode to command mode X.29 PAD message received by PAD

   

Selectable possible Value mandatory

PAD parameter meaning

Optional

0

No time out function

20

Value 50ms give time out

255 1-254 [ Table 2-4] Par. 4 Selection of Idle Time Delay

BRBRAITT : March-2007

8

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Parameter 5 : Ancillary Device Control If data is sent from the terminal to the PAD from paper tape, cassette or floppy disk, for instance, the PAD needs to be able to control the flow. Parameter 5 decides whether Flow Control is to be used or not. The characters X – ON and X – OFF are used for controlling the automatic sender in the terminal Selectable possible value Mandatory

PAD parameter meaning

Optional

0

No use of X – ON (DC1) and X – OFF (DC3)

1

Use of X – ON and X – OFF for flow Control

[Table 2-5] Par . 5 Ancillary Device Control Parameter 6 : Control of PAD Service Signals Recommendation X.28 defines the commands which an operator can give the PAD in order to carry out what he wants. the PAD answers with “Service Signals” to tell the operator what happened in the network as a result of the command Parameter 6 is used to decide which Service Signals are to be sent to the terminal The parameter value 0 means that the operator gets no messages whatsoever from the network, at call set – up, for example. The parameter value 1 + 4 means that all Service Signals are sent to the terminal.

BRBRAITT : March-2007

9

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Selectable possible value Mandatory

PAD parameter meaning

Optional

0

No service signals from PAD

1

Service signals, except prompt

4

PAD prompt service signal 5

All service signals (4 + 1) [ Table 2-6] Par . 6 PAD Service Signals

Parameter 7: Selection of operation of PAD on receipt of Break Signal from the start – stop DTE. When the operator at the asynchronous terminal holds down the BREAK key, the physical line up to the PAD will be put into continuous space. This condition cannot be sent directly via the Packet Switching Network, but we must still be able to convey this break to the computer. Parameter 7 defines several different ways of transmitting a break in the packer network. The one that is to be used depends very much on the computer at the other end. Parameter value 2 (Send RESET packet) means P(S) = 0 and can result in lost packets. Parameter value 21 means that first of all an INTERRUPT packet is sent to the computer from the PAD and then an X.29 packet which states that the PAD has received a BREAK from the asynchronous terminal.

BRBRAITT : March-2007

10

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Selectable possible value Mandatory

PAD parameter meaning

Optional

0 1 2 4 8 16 21

Do nothing Send INTERRUPT packet Send RESET packet Send “Indication of break” PAD message Escape to command phase Discard output to terminal Discard output, send INTERRUPT and “Indication of break” (1+4+16)

[Table 2-7 ] Par.7 Procedure on Break Parameter 8 : Discard Output This parameter is not to be set by the operator at the terminal but only by the X.25 computer via the X.29 protocol Parameter 8 is used together with parameter 7 with a value of 21. It tells the PAD whether any data that may be stored in the output butter for sending to the terminal is to be discarded or sent. Selectable possible value Mandatory

PAD parameter meaning

Optional

0

Normal data delivery

1

Discard Output

BRBRAITT : March-2007

11

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

[Table 2-8] Par. 8 Discard Output Parameter 9 : Padding after Carriage Return If a printing terminal with a mechanical printing device is used, it takes a little time for the printing carriage to go back when “ Carriage Return” has been pressed. For terminals like this, it is possible to put in up to 7 padding characters after CR in parameter 7. These padding characters are either characters which are not printed out on the terminal or simply a pause which corresponds to the number of characters the parameter value states. Selectable possible value Mandatory

PAD parameter meaning

Optional

0

No padding

1-7

Number of padding characters inserted after carriage return.

[Table 2-9] Par. 9 Padding after CR Parameter 10: Line Folding This is a parameter which is mainly interesting for printing terminals which hammer away at the same spool at the end of a line if a “CR” does not come at the right place. The PAD makes sure a “CR” is inserted after the number of characters decided on, using the parameter value in Parameter 10. If padding has been specified in Parameter 9, these padding characters will also be inserted into the data streams.

BRBRAITT : March-2007

12

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Selectable possible value Mandatory

PAD parameter meaning

Optional

0

No line folding

1-255

Number of printable characters per line

[ Table 2-10] Par. 10 Line Folding Parameter 11 : Binary speed of start – stop mode DTE This is a “ read – only” parameter and cannot be changed either by the X.25 terminal or by the operator at the asynchronous terminal. The parameter can be used by an X.25 terminal in order to find out what speed the asynchronous terminal uses.

BRBRAITT : March-2007

13

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Selectable possible value Mandatory

PAD parameter meaning

Optional

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

110 bps 134.5 bps 300 bps 1200 bps 600 bps 75 bps 150 bps 1800 bps 200 bps 100 bps 50 bps 75/1200 bps 2400 bps 4800 bps 9600 bps 19200 bps 48000 bps 56000 bps 64000 bps

[ Table 2- 11] Par. 11 Terminal Data Rate Parameter 12 : Flow control of the PAD by the start – stop mode DTE Here the terminal can control the flow from the PAD in the same way as the PAD can control the flow from the terminal. The may be useful if received data is to be printed out or stored on a diskette. The PAD will in turn be forced to control the flow the X.25 computer. But this is of course taken care of in the X.25 protocol by the window filling up or by the PAD sending an RNR packet.

BRBRAITT : March-2007

14

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Selectable possible value Mandatory

PAD parameter meaning

Optional

0

No use of X – ON (DC1) and X – OFF (DC – 3) No flow control Flow control by use of X- ON and X - OFF

1

[ Table 2-12] Par. 12 Flow control of the PAD Parameter 13 : Linefeed insertion after CR Some terminals insert a “Linefeed” automatically after a “Carriage Return”, others do not. Most Visual Display terminals can be programmed for whatever is wanted. Parameter 13 is the PAD is required to insert a “Linefeed” after CR. It is possible to have different functions for data to and form the terminal respectively. Selectable possible value Mandatory

PAD parameter meaning

Optional

0 1 2 4 5 6 7

No linefeed insertion Insert LF after each CR to the terminal Insert LF after each CR from the terminal Insert LF after each CR sent as echo to the terminal Combination of (1+4) Combination of (2+4) Combination of (1+2+4)

[ Table 2-13] Par. 13 Linefeed insertion

BRBRAITT : March-2007

15

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Parameter 14 : Linefeed Padding In the same way as padding characters may be necessary after “CR” for a mechanical terminal, padding characters may be required after an “LF” sent to the terminal. Using this parameter, the number of padding characters, between 0 and 7 can be selected. Selectable possible value Mandatory

PAD parameter meaning

Optional

0

No linefeed padding

1-7

Number of characters

[Table 2-14] Par. 14 Linefeed Padding Parameter 15: Editing In command mode it is always possible to edit what is sent from the terminal. With Parameter 15, the user can select whether it should be possible in data transfer state to edit (i.e. correct wrongly entered characters) in the PAD input buffer before the packets are sent. Parameter 16,17 and 18 define which keys are to be used for editing. If Parameter 15 is set at 1 (i.e. edit), this affects the PAD functions in the following way: 

The packets are not sent off when the “Idle Timer” runs out.



The packets are not sent off when they are full, but instead when the “editing buffer” is full.

If the Editing function is selected, it is important to bear in mind the conditions that apply to “Data packet Forwarding”.

BRBRAITT : March-2007

16

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Selectable possible value Mandatory

PAD parameter meaning

Optional

0

No use of editing in data transfer state

1

Editing in data transfer state

[Table 2-15] Par. 15 Editing Parameter 16 : Character Delete Parameter 17 : Line Delete These parameter are used to specify which characters mean “Character Delete” and “Line Delete” if “Editing” has been selected in Parameter 15 Parameter 18 : Line Display Line Display is a function which is useful when the user has edited text and wants to see what it looks like in its final form. The parameter value specifies the binary value of the ASCII characters which are to be used for “Line Display”. Selectable possible value Mandatory

PAD parameter meaning

Optional

0-127

One Character from IA5 (ASCII)

[ Table 2-16] Par . 16 Character Delete Par . 17 Line Delete Par . 18 Line Dispaly BRBRAITT : March-2007

17

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Parameter 19 : Editing, PAD service signals Parameter 15 determines whether the terminal operator will be able to edit the characters available in the buffer in The PAD during data transfer. Parameter 16,17 and 18 define which characters are to signify: 

Character delete (default 7F (hex) = 127 (dec) = DEL



Line delete (default 1 B (hex) = 24 (dec) = CAN)



Line display (default 12 (hex) = 18 (dec) = DC2

Parameter 19 defines which characters the PAD will respond with when it received a “character delete” or” character form the terminal. Even if parameter 15 is 0 i.e. no editing in data transfer mode, it is still possible to use “character delete” or “line delete” in command mode to allow editing of the PAD command currently being written. If parameter 19 is 0, the PAD will execute “delete” , but there will be no response visible on the VDU. The default values of “Character – delete PAD service signal” and “Line – delete PAD service signal “specified by CCITT are adapted to printers and VDUs respectively. If parameter 6, “PAD service signals” is 0, the PAD will not respond to a “ delete” in command mode. The command will nevertheless be executed.

BRBRAITT : March-2007

18

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Selectable possible value Mandatory

PAD parameter meaning

Optional PAD answer to :

0 1 (for printing terminals)

Character delete

Line delete

No answer

No answer

IA5 character “\” (5Chex =92 dec)

2 (for display terminals

IA5 character “BS SP BS” (08 – 20 – 08hex) (8 – 32 – 8dec)

3 32-86

One IA5 character (same as per value

IA5 characters “XXX” + format effector (CR+LF) (58 – 58 – 58hex) (88 – 88 – 88dec) IA5 characters BS SP BS” repeated for each graphic character being deleted IA5 characters “XXX” + format effector

[ Table 2-17] Par. 19 Editing , Pad Service Signals Parameter 20 : Echo mask When an operator sitting at an asynchronous terminal types on the key board, the characters must echo somewhere in order finally to come up on the screen. There are three places the echo can come from” – the terminal itself – the PAD – the host at the other end of the packet switched network BRBRAITT : March-2007

19

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Local Echo In an asynchronous protocol it is the operator himself who checks that the characters arrive correctly by studying the “echo” on the screen. Thus, if the terminal is allowed to make the echo itself, the operator loses some of the control over the synchronous link to the PAD. Echo from the host If the host is chosen to echo the characters, parameter 4 “idle timer”, must be set at a low value. In spite of this the communication will appear “sluggish” , due to the delay in the network and the packeting. Furthermore, most packets will only contain one character, which is then echoed by the host in a new packet. The tariff charges in most networks are based on commenced segments of 64 characters. Consequently, for every character transmitted, two segments are charged for ! Echo from the PAD Only one alternative remains then, echo form the PAD . Most asynchronous terminals or PC communication programs have, however, a good deal of built in intelligence, and they react to many of the control characters we want to use to control the host, parameter 20 helps us to filter off the characters we do not wish to be echoed. Example : The host uses the character FF (Form Feed) to denote a new page in a document. At the same time, our terminal interprets this character as “Clear Screen”. If the PAD echoes this character, our screen is cleared every time we send a “new page” command to the host. The exceptions for this parameter are the X – ON and X – OFF characters (11 and 13 (hex) = 17 and 19 (dec). The PAD never echoes these characters if any of the parameters 5, 12, or 22 has a value other than 0

BRBRAITT : March-2007

20

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Selectable possible value Mandatory

PAD parameter meaning

Optional

0 1 2 4 8 16 32 64 128

No echo mask (AII character echoed) No echo of No echo of , , No echo of , No echo of <ESC>, <ENQ> No echo of , , <STX>, <SOH>, <EOT>, <ETB>, <ETX>, No echo of editing of characters as designated by parameter 16, 17 and 18 No echo of all other characters in column 0 and 1 not mentioned above and

[Table 2-18] Par . 20 Echo Mask Parameter 21 : Parity treatment This parameter controls the way the PAD treats the parity bit, bit 8, in the asynchronous character. The value 0 in this parameter means that the PAD does not check the parity of the characters from the terminal. Nor does the PAD generate any parity bit in the characters sent to the terminal. Note that this need not imply the parity bit is missing, but simply that the value is not significant.

BRBRAITT : March-2007

21

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Selectable possible value Mandatory

PAD parameter meaning

Optional

0

No parity checking or generation 1

Parity checking

2

Parity generation

3

Parity checking and parity generation

[ Table 2-19] Par. 21 Parity Treatment Parameter 22 : Page wait An asynchronous DTE can control the flow of characters from the PAD by sending X – OFF and X – ON. The terminal does this when its buffer is almost full. Sometimes, however, it is appropriate to stop the characters from the PAD for reasons other than that the buffer is full. It might be, for instance, to allow a new sheet of paper to be fed into a printer with single sheet paper feed, or to store received character on diskette. Parameter 22 counts the number of line feeds the next contains. When the number of LFs is equal to the value selected for parameter 22, the PAD waits for a signal from the terminal before it sends further characters. This signal from the DTE is X – ON. If parameter 6 is not 0, (PAD service signals), the PAD sends a “Page wait” PAD service signal to the terminal when it enters “page wait” condition. The service signal consists of the following characters. PAGE

BRBRAITT : March-2007

22

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

The PAD zeroes its line feed counter after the following have been received. 

X – ON from the terminal



a “data forwarding” signal from the DTE (i.e. a packet will be dispatched)



an LF from the DTE, which the PAD is to echo



a “line delete” from the DTE

Selectable possible value Mandatory

PAD parameter meaning

Optional

0

Page wait disabled 1-22

23 24-255

Number of line feed characters Considered by the PAD for the page wait function

[ Table 2-20] Par. 22 Page Wait

3. X.28 COMMANDS Recommendation X.28 defines the interface between the asynchronous terminal and the PAD. It mainly deals with the commands language between the terminal and the PAD. The commands in X.28 makes it possible to do the following: 

set up and clear a virtual call



select a standard profile which suits the terminal

BRBRAITT : March-2007

23

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)



alter the values in the PAD parameters



ask to be allowed to read the values the apply to the PAD parameters

  

send an INTERRUPT packet ask for information on the status of a virtual call request reset for a virtual call

Every command is ended with CR or +. These two characters are called Command Delimiters. Two examples of commands are : PAR? 1, 13, 15, “I want to know what values Parameters 1, 13 and 15 have” SET 1:0, 2:1 “Alter parameter 1 to value 0 and parameter 2 to value 1” Command

Meaning

PAD Response

STAT

Request for status of a virtual call

FREE or Engaged CLR CONF or CLR ERR PAR 1:1 2:0 etc PAR 3:332 5:1 Acknowledgement

CLR

Request for clearing of a virtual call

PAR?

What values have all my parameters?

PAR 3,5

What values have parameters 3 and 5?

SET 3:4, 5:1

Set parameter 3 and 5 to values 4 and 1 resp.

SET? 3:4, 5:1

Set parameter 3 to value 4 and parameter 5 to PAR 3:4, 5:0 value 0, then confirm by sending back the new values.

PROF 1

Bring up a standard profile for parameter Acknowledgement values. (e.g. number)

RESET

Request for reset of the virtual call

Acknowledgement

INT

Send an INTERRUPT packet

Acknowledgement

C number

Connect to (number)

COM or error The “number” may consist of the X.121 address message and user name and password [Table 3-1] X.28 Commands from terminal to PAD

BRBRAITT : March-2007

24

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

X.28 SERVICE SIGNALS The responses which the PAD sends to the commands from the terminals are called Service Signals. The PAD also sends Service Signals to keep the operator at the X.28 terminal informed about what is happing to his virtual call.When a virtual call is to be established, the PAD will send COM(Call Connected) it the network manages to set it up. If it fails, the PAD sends a CLR with information about why the connection was unsuccessful. Format of the service signal

Meaning

RESET

DTE(diagn. Code)

The VC has been reset from the remote DTE

RESET

ERR (diagn. Code)

Reset because of a local procedure error

RESET

NC

Reset because of network congestion

CLR

See [table 2-23]

The VC has been cleared

COM

Call connected

ERROR

Wrong command to PAD

ENGAGED

Response to STAT command. A VC is connected Response to STAT command. No VC is connected Response to PAR? Or SET? commands

FREE PAR

(par number value)

[ Table 3-2] PAD Service Signals Service signal CLR + OCC NC INV NA ERR RPE

Meaning

Number busy Network congestion Invalid facility request Access barred, e.g. trying to access a CUG Local procedure error. The PAD has discovered a protocol violation Remote procedure error. The network has discovered a

BRBRAITT : March-2007

25

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

NP DER PAD DTE

protocol violation at the other X.25 interface. Not obtainable E.g. number does not exist Out of order. The called access link is not up PAD clearing The PAD is clearing as a result of a received “Invitation to clear” The X.25 host has cleared the call [Table 3-3] Clear Indication PAD Service Signals

4. X.29 – PROTOCOL BETWEEN THE PAD AND THE X.25 TERMINAL The X.29 protocol is a protocol above packet level since it uses a virtual call in X.25 to transport the information. Each level in the OSI model has its own “header” which constitutes the actual protocol. This header is normally in the Data field at the next level down. X.29 belongs in fact to the network protocol, and has no function in the actual data transfer when the connection has been made. Your must therefore be able to decide even at Level 3 whether the data in the Data field of a DATA packet belongs to the network (=X.29) or if it is user data. The Q Bit in the DATA packet has this function. If the Q Bit = 1, the Data field consists of PAD messages, i.e. X.29 protocol, and if the Q Bit = 0, then it is user data. PAD messages are used by the X.25 host to set or read X.3 parameters in the PAD, and to receive an indication that the X.28 terminal has sent BREAK and also to send INVITATION TO CLEAR.

Level 4

User Data or X.29 Protocol

Level 3 Level 2

Packet header Frame header

Frame Trailer

[Fig 4-1] Protocol levels

BRBRAITT : March-2007

26

“DATA NETWORKS” FOR JTOs PH-II - PAD & Related Protocols (X.3, X.28 & X.29)

Q=1

D=0/1

SN=01

LCGN LCN

P( R )

M=0/1

P( S )

0

X.29 Protocol [Fig 4-2] Data Qualifies packet PAD MESSAGES AND FORMATS An X.25 DTE can request access to the PAD parametes which apply to a virtual ball by sending a PAD message. When the PAD receives a request to alter a PAD parameter, all the data which has still not been sent to the X.25 terminal will first be sent from the PAD. The PAD message also works as a Data Forwarding Signal and the PAD assembles and sends of f the last packet. The first byte in the user data field indicates what type of PAD message it is The following PAD message and their codes are used: hex code

meaning

00

Parameter Indication PAD message

01

Invitation to Clear

02

Set parameters

03

Indication of Break

04

Read parameters

05

Error message

6

Set and read parameters

The subsequent octets are read in pairs, where the first octet contains the number of the parameter concerned and the second contains the parameter value When the PAD has received a command which contains READ, the PAD will respond with a Parameter Indication Message, containing all the new parameter values.

BRBRAITT : March-2007

27