PHS MoU Document
B-IF2.02-02-TS
Title: Public Personal Handy-Phone System : Interface between Public
Cell Station and ISDN-based PHS Switching Center-Layer 3
Specification
Version: 02
Date: July 31, 1998
PHS MoU Classification: Unrestricted
List of contents:<Summary>
1. Relation with international standards
2. Differences from ITU-T Recommendation Q.931.
3. References
4. Items for further study< Layer 3 Specification >1 General
2 Overview of call control
3 Message functional definitions and content
4 General message format and information elements coding
5 Circuit-switched call control procedures* 6 Packet communication procedures* 7 User signaling bearer service call control procedures* 8 Circuit-mode multirate (64 kbit/s base rate) procedures
9 List of system parameters
The clauses marked by * are not included in this specification.
Number of pages: 227

PHS MoU Group
c/o Association of Radio Industries and Businesses (ARIB)
14F, Nittochi Bldg., 4-1, Kasumigaseki 1-choume, Chiyoda-ku, Tokyo 100, Japan
TEL +81-3-5510-8599 FAX +81-3-3592-1103© PHS MoU Group 1998

PHS MoU Document
B-IF2.02-02-TS
Version01

History of Revised Versions
Date
OutlineApril 17, 1996 Established01

Dec. 17, 1996

02

July 31,1998

x Document No. is changed. (Formerly IF2.02)
x Document title is changed. (Formerly Personal
Handy-Phone System Public Cell Station-ISDN
Interface-Layer 3 Specification-)x Takeover of Annex of B-IF2.51(TR) for

upgrading B-IF2.51-02-TR to TS and error
correction

B-IF2.02-02-TS

Public Personal Handy-Phone System:
Interface between Public Cell Station and ISDN-based PHS
Switching Center-Layer 3 Specification< Summary >1. Relation with International Standards
This specification conforms to ITU-T Recommendation Q.931 in principle and specifies thesignalling system consistent with the air interface specified by "PERSONAL HANDY PHONESYSTEM ARIB STANDARD (RCR STD-28) VERSION 2".
2. Differences from ITU-T Recommendation Q.931
This specification is to be revised in the near future in order to include items specified in ITU-T
Q.931 as many as possible. For the time being the minimum set specification, which is a sub-set of
ITU-T Q.931, is attached as a reference which is necessary to realize the minimum PHS functions.
The differences between the minimum set specification and ITU-T Q.931 are summarized in thefollowing table.
3. References
ITU-T Recommendation Q.931
ARIB STANDARD RCR STD-28
PHS MoU Specification IF1.00, IF2.00, IF2.03
4. Items for Further Study
It is under study to include items, which are not included in the minimum set specification at present
but specified in ITU-T Q.931, in this layer 3 specification as many as possible in the near future.

B-IF2.02-02-TS(1)

Table 1/IF2.02(Q.931)
Differences between the minimum set specification and ITU-T Q.931
Item1) Common terms

2) Protocol discriminator3) Mode4) Messages for circuit modeconnection control

5) Information elements forcircuit mode connection
control6) Connection configurations

7) First response for incomingcall8) Action of public cell station
which cannot confirm endto-end call connection(2) B-IF2.02-02-TS

Difference(1) "user" is changed to "public cell station"and "network" to "ISDN"(2) "U0, U1, ..." which are the call states of
the user side are changed to "C0, C1, ..."
which are the call states of the public cellstation side.
New protocol discriminator value is used.
"packet mode" and "user signalling bearer
service" are not used.
(1) SETUP ACKNOWLEDGE message is notused.
(2) RESUME, RESUME ACKNOWLEDGE,
RESUME REJECT, SUSPEND, SUSPENDACKNOWLEDGE, and SUSPENDREJECT messages are not used.
(3) INFORMATION message is not used.
(1) More data information element, Congestion
level information element, Call identity
information element, Network-specificfacilities information element, Display
information element, Date/time information
element, Transit network selection
information element, and User-user
information element are not used.
(2) Sending complete information element is
not used.
(3) Keypad facility information element and
Signal information element are not used.
Point-to-point connection between public cellstation and ISDN are used. In case of incoming
call to public cell station, DL-UNITDATAREQUEST primitive is sent from ISDN. And
call state management in above casecorresponds to that of point-to-multipointconnection, for which call abort status isdefined.
The first response to SETUP message frompublic cell station must be CALLPROCEEDING message. Only public cellstation which can confirm consistency of endto-end connection sends this message. (WhenCONNECT message or other one frompersonal station is received.)
Public cell station which can not confirm endto-end call connection releases the callreference and shall not send any messages to
ISDN.

Reasons(1) This change makes clear what"user" and "network" mean.
(2) The call states refer to the public
cell station (CS).

This interface is used as NNI.
Usage of the both modes has not beenclarified.
(1) Usage has not been clarified.
(2) Not provided in this specification.
(3) Messages and information elements
for stimulus procedure are out of
scope.

(1), (2) Not provided in thisspecification.
(3) Messages and information elements
for stimulus procedure are out of
scope.

It is out of scope to connect multiple
public cell stations to an interface.
Invalid messages for an incoming callare also to be avoided.

These conditions for sending the first
response is for the ISDN not to receive
invalid messages.

Invalid messages for an incoming callare to be avoided.

Table 1/IF2.02(Q.931) (continued)
Item9) Circuit-switched call control
procedures

10) Deletion of the information
elements from messages11) NOTIFY message12) SETUP message13) Call reference information
element
14) Call reference information
element
15) Bearer capability
information element
16) Call state information
element17) Calling/called party number
information element

18) Progress indicator
information element
19) Progress indicator
information element

Difference(1) The description of overlap sending andreceiving are deleted.
(2) The description of transit network
selection, call rearrangements, bearercapability selection, and high layer
capability selection are deleted.
(3) Channel negotiation procedure is notused.
(1) Bearer capability information element is
not provided for each of ALERTING,
CALL PROCEEDING, CONNECT, and
PROGRESS messages.
(2) Bearer capability information element is
not provided for NOTIFY message.
(3) Channel identification information
element is not provided for each of
ALERTING and CONNECT messages.
NOTIFY is used only for ISDN-to-public cellstation direction.
Calling party number information element inoutgoing call from public cell station andCalled party number information element inincoming call to/outgoing call from public cellstation are mandatory.

Length of call reference value is fixed 2 octets.
Dummy call reference number is not used.
Octets 6,7 (User information layer 2 protocol
and layer 3 protocol) are not used.
(1) C2/N2 (Overlap sending),(2) C25/N25 (Overlap receiving),(3) C15/N15 (Suspend request),(4) C17/N17 (Resume request) are not used.
Only international number / national number /network specific number / reserved forextension / spare are used as Type of number.
Only ISDN/telephony numbering plan /national standard numbering plan / private
numbering plan / reserved for extension /spare are used as Numbering plan.
The network is regarded as ISDN on internetwork interworking"private network serving local user" is not
used.

Reasons(1), (2) Not provided in thisspecification.
(3) In normal call, public cell station
make choice of channel.

(1), (2) Bearer capability information
element in these messages are forthe bearer capability selection,
which is not provided in thisspecification.
(3) These messages can not be the first
response to SETUP message.

Not provided in this specification.
Calling party number information
element in outgoing call is necessary
for specifying a calling side.
Called party number information
element in outgoing call is necessary
for specifying a called side.
Called party number information
element in incoming call is necessary
for specifying a called side.
The number of active incoming calls
can be large.
Not provided in this specification.
Packet mode is not provided in thisspecification.
(1), (2) Overlap sending and receiving
are not provided in thisspecification.
Other Type of number and Numbering
plan are not provided in thisspecification.

This is to clarify the interworking withother network.
Public cell station serving private
network has not been defined.

B-IF2.02-02-TS(3)

Table 1/IF2.02(Q.931) (end)Item20) Timer

21) Constraints in incoming call22) Annex A23) Annex C24) Annex D25) Annex E
26) Annex G27) Annex H28) Annex K29) Annex L30) Appendix I
31) Appendix II32) Appendix IV(4) B-IF2.02-02-TS

Difference(1) The following timers are not used at the
ISDN side: T302, T304, T307, T320.
(2) The following timers are not used at the
public cell station side:
T302, T304, T318, T319.
(3) T303 on the ISDN is changed to 4 through5 seconds.
(1) Channel identification information
element in incoming call to public cellstation is constrained as follows;
1) Information channel selection fieldindicates "B1 channel" or "B2 channel",and Preferred/Exclusive field indicates"exclusive", or2) Information channel selection fieldindicates "any channel", and Preferred/Exclusive field indicates "indicatedchannel is preferred".
(2) If there is no response for re-transmitted
SETUP message, cause No. 20"subscriber absent" is sent to the callinguser side.
(3) Public cell station receiving an incoming
call with bearer capability which is not
implemented sends cause No. 65 "Bearercapability not implemented" only if
establishment of the end-to-end
connection is possible.
(4) The local action of the public cell station
is not described.
(5) Section 5.2.9 is not used.
The above changes are applied.
Not included.
Not included.
Not included.
Not included.
The above changes are applied.
Not included.
Not included.
Cause No. 20 is added.
Not included.
Descriptions beyond the bound of an interface
are arranged as Appendix.

Reasons(1), (2) These are timers for thefunctions which are not provided inthis specification.
(3) The value depends on requirementof public cell station.

(1) Channel is to be hunt by the public
cell station.
(2) This cause value is for mobile
communicatio(3) Action is clarified when "subscriber
absent" situation, which is peculiar
to mobile communication, andincoming call with unimplemented
bearer capability occur at the sametime.
(4) The description is for the local
action of terminal equipment and is
not applied to the public cellstation.
(5) The connection is restricted topoint-to-point connection.

Not provided in this specification.
Not required.
Not provided in this specification.
Not required.
Not provided in this specification.
Not provided in this specification.
This is a cause value for mobile
communications.
Not provided in this specification.
It is necessary to clarify the details
beyond the bound of an interface.

B-IF2.02-02-TS
Public Personal Handy-Phone System
Interface Between Public Cell Station and ISDN-Based PHS
Switching Center-Layer 3 Specification

This specification specifies the layer 3 of the Personal Handy-Phone System public cell station-ISDN
interface.
This specification conforms to ITU-T Recommendation Q.931 in principle. The minimum set
specification, which is a sub-set of ITU-T Q.931, is attached as a reference specification which isnecessary to realize the minimum PHS functions.
Note :

This means that the minimum functions of PHS can be realized with the minimum set
specification and does not restrict implementation of functions which are not specified in theminimum set specification. This specification is to be revised in the near future in order toinclude items, which are not included in the minimum set specification at present but
specified in ITU-T Q.931, as many as possible.

Attachment
Personal Handy-Phone System Public Cell Station-ISDN Interface Layer 3 Specification- Minimum Set Specification -B-IF2.02-02-TS(5)

B-IF2.02-02-TS
Public Personal Handy-Phone System:
Interface between Public Cell Station and ISDN-based PHS
Switching Center-Layer 3 Specification

Contents
1 General..........................................................................................................................................

1

1.1 Scope of the specification.............................................................................................................

1

1.2 Application to interface structures................................................................................................

1

2 Overview of call control ........................................................................................................................

2

2.1 Circuit switched calls....................................................................................................................

2

2.1.1 Call states at the public cell station side of the interface .......................................................

2

2.1.1.1 Null state (C0) ..................................................................................................................

2

2.1.1.2 Call initiated (C1).............................................................................................................

2

2.1.1.3 Overlap sending (C2)* .....................................................................................................

3

2.1.1.4 Outgoing call proceeding (C3) .........................................................................................

3

2.1.1.5 Call delivered (C4) ...........................................................................................................

3

2.1.1.6 Call present (C6) ..............................................................................................................

3

2.1.1.7 Call received (C7) ............................................................................................................

3

2.1.1.8 Connect request (C8)........................................................................................................

3

2.1.1.9 Incoming call proceeding (C9).........................................................................................

3

2.1.1.10 Active (C10) ...................................................................................................................

3

2.1.1.11 Disconnect request (C11) ...............................................................................................

3

2.1.1.12 Disconnect indication (C12)...........................................................................................

3

2.1.1.13 Suspend request (C15)* .................................................................................................

4

2.1.1.14 Resume request (C17)* ..................................................................................................

4

2.1.1.15 Release request (C19).....................................................................................................

4

2.1.1.16 Overlap receiving (U25)*...............................................................................................

4

2.1.2 ISDN call states ......................................................................................................................

4

2.1.2.1 Null state (N0) ..................................................................................................................

4

2.1.2.2 Call initiated (N1).............................................................................................................

4

B-IF2.02-02-TSi2.1.2.3 Overlap sending (N2)* .....................................................................................................

4

2.1.2.4 Outgoing call proceeding (N3).........................................................................................

4

2.1.2.5 Call delivered (N4)...........................................................................................................

4

2.1.2.6 Call present (N6) ..............................................................................................................

4

2.1.2.7 Call received (N7) ............................................................................................................

4

2.1.2.8 Connect request (N8) .......................................................................................................

5

2.1.2.9 Incoming call proceeding (N9).........................................................................................

5

2.1.2.10 Active (N10)..................................................................................................................

5

2.1.2.11 Disconnect request (N11) ...............................................................................................

5

2.1.2.12 Disconnect indication (N12) ..........................................................................................

5

2.1.2.13 Suspend request (N15)* .................................................................................................

5

2.1.2.14 Resume request (N17)* ..................................................................................................

5

2.1.2.15 Release request (N19) ....................................................................................................

5

2.1.2.16 Call abort (N22) .............................................................................................................

5

2.1.2.17 Overlap receiving (N25)*...............................................................................................

5

2.2 Packet-mode access connections * ...............................................................................................

5

2.3 Temporary signalling connections * .............................................................................................

5

2.4 States associated with the global call reference............................................................................

6

2.4.1 Call states at the public cell station side of the interface .......................................................

6

2.4.1.1 Null (Rest 0) .....................................................................................................................

6

2.4.1.2 Restart request (Rest 1) ....................................................................................................

6

2.4.1.3 Restart (Rest 2).................................................................................................................

6

2.4.2 Call states at the ISDN side of the interface...........................................................................

6

2.4.2.1 Null (Rest 0) .....................................................................................................................

6

2.4.2.2 Restart request (Rest 1) ....................................................................................................

6

2.4.2.3 Restart (Rest 2).................................................................................................................

6

3 Message functional definitions and content ..........................................................................................

7

3.1 Messages for circuit mode connection control .............................................................................

8

3.1.1 ALERTING.............................................................................................................................

8

3.1.2 CALL PROCEEDING............................................................................................................

9

3.1.3 CONNECT .............................................................................................................................

9ii

B-IF2.02-02-TS3.1.4 CONNECT ACKNOWLEDGE .............................................................................................

10

3.1.5 DISCONNECT .......................................................................................................................

10

3.1.6 INFORMATION*...................................................................................................................

10

3.1.7 NOTIFY..................................................................................................................................

11

3.1.8 PROGRESS ............................................................................................................................

11

3.1.9 RELEASE...............................................................................................................................

12

3.1.10 RELEASE COMPLETE.......................................................................................................

12

3.1.11 RESUME* ............................................................................................................................

13

3.1.12 RESUME ACKNOWLEDGE* ............................................................................................

13

3.1.13 RESUME REJECT*.............................................................................................................

13

3.1.14 SETUP ..................................................................................................................................

13

3.1.15 SETUP ACKNOWLEDGE* ................................................................................................

14

3.1.16 STATUS................................................................................................................................

14

3.1.17 STATUS ENQUIRY .............................................................................................................

14

3.1.18 SUSPEND*...........................................................................................................................

14

3.1.19 SUSPEND ACKNOWLEDGE*...........................................................................................

14

3.1.20 SUSPEND REJECT* ...........................................................................................................

14

3.2 Messages for packet mode connection control * ..........................................................................

14

3.3 Messages for user signalling bearer sevice control * ...................................................................

14

3.4 Messages with the global call reference .......................................................................................

15

3.4.1 RESTART ...............................................................................................................................

15

3.4.2 RESTART ACKNOWLEDGE ...............................................................................................

16

3.4.3 STATUS..................................................................................................................................

16

4 General message format and information elements coding...................................................................

17

4.1 Overview.......................................................................................................................................

17

4.2 Protocol discriminator...................................................................................................................

18

4.3 Call reference................................................................................................................................

19

4.4 Message type.................................................................................................................................

20

4.5 Other information elements ..........................................................................................................

22

4.5.1 Coding rules............................................................................................................................

22

4.5.2 Extensions of codesets............................................................................................................

25

B-IF2.02-02-TS

iii

4.5.3 Locking shift procedure..........................................................................................................

26

4.5.4 Non-locking shift procedure ...................................................................................................

27

4.5.5 Bearer capability.....................................................................................................................

29

4.5.6 Call identity* ..........................................................................................................................

36

4.5.7 Call state .................................................................................................................................

36

4.5.8 Called party number ...............................................................................................................

38

4.5.9 Called party subaddress ..........................................................................................................

40

4.5.10 Calling party number ............................................................................................................

42

4.5.11 Calling party subaddress.......................................................................................................

44

4.5.12 Cause ....................................................................................................................................

46

4.5.13 Channel identification ..........................................................................................................

46

4.5.14 Corgestion level* ..................................................................................................................

50

4.5.15 Date/time* ............................................................................................................................

50

4.5.16 Display*................................................................................................................................

50

4.5.17 High layer compatibility.......................................................................................................

50

4.5.18 Keypad facility* ...................................................................................................................

53

4.5.19 Low layer compatibility........................................................................................................

53

4.5.20 More data*............................................................................................................................

64

4.5.21 Network-specific facilities*..................................................................................................

64

4.5.22 Notification indicator............................................................................................................

64

4.5.23 Progress indicator .................................................................................................................

65

4.5.24 Repeat indicator....................................................................................................................

67

4.5.25 Restart indicator....................................................................................................................

68

4.5.26 Segmented message ..............................................................................................................

69

4.5.27 Sending complete*................................................................................................................

70

4.5.28 Signal* ..................................................................................................................................

70

4.5.29 Transit network selection*....................................................................................................

70

4.5.30 User-user*.............................................................................................................................

70

4.6 Information element for packet communications * ......................................................................

70

5 Circuit-switched call control procedures...............................................................................................

71

5.1 Call establishment at the originating interface .............................................................................

71

iv

B-IF2.02-02-TS

5.1.1 Call request .............................................................................................................................

72

5.1.2 B-channel selection - Originating...........................................................................................

72

5.1.3 Overlap sending* ....................................................................................................................

73

5.1.4 Invalid call information ..........................................................................................................

73

5.1.5 Call proceeding.......................................................................................................................

73

5.1.5.1 Call proceeding.................................................................................................................

73

5.1.5.2 Call proceeding, overlap sending* ...................................................................................

74

5.1.6 Notification of interworking at the originating interface .......................................................

74

5.1.7 Call confirmation indication...................................................................................................

74

5.1.8 Call connected ........................................................................................................................

75

5.1.9 Call rejection ..........................................................................................................................

75

5.1.10Transit ISDN selection* .........................................................................................................

75

5.2 Call establishment at the destination interface .............................................................................

75

5.2.1 Incoming call ..........................................................................................................................

75

5.2.2 Compatibility checking...........................................................................................................

76

5.2.3 B-channel selection - Destination...........................................................................................

76

5.2.4 Overlap receiving*..................................................................................................................

77

5.2.5 Call confirmation....................................................................................................................

77

5.2.5.1 Response to SETUP ........................................................................................................

77

5.2.5.2 Receipt of CALL PROCEEDING ...................................................................................

78

5.2.5.3 Clearing of destination Public CS during SETUP at the destination ..............................

78

5.2.5.4 Call failure........................................................................................................................

79

5.2.6 Notification of interworking at the terminating interface ......................................................

79

5.2.7 Call accept ..............................................................................................................................

80

5.2.8 Active indication.....................................................................................................................

80

5.2.9 Call procedure for the grouped multiple interfaces ...............................................................

81

5.3 Call clearing..................................................................................................................................

81

5.3.1 Terminology............................................................................................................................

81

5.3.2 Exception conditions ..............................................................................................................

81

5.3.3 Clearing initiated by the Public CS ........................................................................................

82

5.3.4 Clearing initiated by the ISDN ...............................................................................................

83

B-IF2.02-02-TSv

vi

5.3.4.1 Clearing when tones/announcements provided................................................................

83

5.3.4.2 Clearing when tones/announcements not provided..........................................................

83

5.3.4.3 Completion of clearing.....................................................................................................

84

5.3.5 Clear collision.........................................................................................................................

84

5.4 In-band tones and announcements ................................................................................................

84

5.5 Restart procedure ..........................................................................................................................

85

5.5.1 Sending RESTART message ..................................................................................................

85

5.5.2 Receipt of RESTART message ...............................................................................................

86

5.6 Call rearrangements * ...................................................................................................................

87

5.7 Call collisions ...............................................................................................................................

87

5.8 Handling of error conditions.........................................................................................................

87

5.8.1 Protocol discrimination error..................................................................................................

88

5.8.2 Message too short ...................................................................................................................

88

5.8.3 Call reference error.................................................................................................................

88

5.8.3.1 Invalid Call reference format ...........................................................................................

88

5.8.3.2 Call reference procedural errors.......................................................................................

88

5.8.4 Message type or message sequence errors .............................................................................

89

5.8.5 General information element errors........................................................................................

90

5.8.5.1 Information element out of sequence ...............................................................................

90

5.8.5.2 Duplicated information elements .....................................................................................

90

5.8.6 Mandatory information element errors...................................................................................

90

5.8.6.1 Mandatory information element missing .........................................................................

90

5.8.6.2 Mandatory information element content error .................................................................

91

5.8.7 Non-mandatory information element errors ...........................................................................

91

5.8.7.1 Unrecognized information element ..................................................................................

91

5.8.7.2 Non-mandatory information element content error..........................................................

92

5.8.7.3 Unexpected recognized information element...................................................................

93

5.8.8 Data link reset.........................................................................................................................

93

5.8.9 Data link failure ......................................................................................................................

93

5.8.10 Status enquiry procedure ......................................................................................................

94

5.8.11 Receiving a STATUS message..............................................................................................

95

B-IF2.02-02-TS

5.9 User notification procedure ..........................................................................................................

96

5.10 Basic telecommunication service identification and selection * } .............................................

96

5.11 Signalling procedures for bearer capability selection * }...........................................................

96

5.12 Signalling procedures for high layer compatibility selection * } ...............................................

96

6. Packet communication procedures * ....................................................................................................

96

7. User signalling bearer service call control procedures *......................................................................

96

8. Circuit-mode multirate (64 kbit/s base rate) procedures * ...................................................................

96

9. List of system parameters .....................................................................................................................

97

9.1 Timers in the ISDN side................................................................................................................

97

9.2 Timers in the Public CS side.........................................................................................................

97* : This mark indicates sections which are specified in ITU-T Q.931 but are not included in this PHS MoU
specification.
†} : This mark indicates sections which are to be specified in the next version of the PHS MoU
specification.

B-IF2.02-02-TS

vii

Annex A Public CS side and ISDN side SDL diagrams........................................................................... 105
Annex B Compatibility and address checking.......................................................................................... 187
B.1 Introduction .................................................................................................................................. 187
B.2 Calling side compatibility checking............................................................................................. 187
B.3 Called side compatibility and address checking .......................................................................... 187
B.3.1 Checking of addressing information ...................................................................................... 187
B.3.2 ISDN-to-public cell station compatibility checking .............................................................. 182
B.3.3 User-to-user compatibility checking...................................................................................... 182
B.3.4 Called side action tables ....................................................................................................... 183
B.4 Interworking with existing networks............................................................................................ 184
Annex C Transit network selection * ....................................................................................................... 185
Annex D Extensions for symmetric call operation *................................................................................ 186
Annex E Network specific facility selection * ......................................................................................... 187
Annex F D-channel backup procedures.................................................................................................... 188
F.0 Foreword ....................................................................................................................................... 188
F.1 General .......................................................................................................................................... 188
F.2 D-channel backup procedure ........................................................................................................ 189
F.2.1 Role of each D-channel .......................................................................................................... 189
F.2.2 Switchover of D-channels....................................................................................................... 190
Annex G Use of progress indicators *...................................................................................................... 191
Annex H Message segmentation procedures............................................................................................ 192
H.1 Introduction ................................................................................................................................... 192
H.2 Message segmentation................................................................................................................... 193
H.3 Reassembly of segmented messages ............................................................................................. 193
Annex I Low layer information coding principles ................................................................................... 201
I.1 Purpose .......................................................................................................................................... 201
I.2 Principles ....................................................................................................................................... 201
I.2.1 Definitions of types of information......................................................................................... 201
I.2.2 Examination by network.......................................................................................................... 202
I.2.3 Location of type I information ................................................................................................ 202
I.2.4 Location of type II and III information.................................................................................... 202
viii

B-IF2.02-02-TS

Annex J Low layer compatibility negotiation .......................................................................................... 203
J.1 General .......................................................................................................................................... 203
J.2 Low layer capability notification to the called user...................................................................... 203
J.3 Low layer compatibility negotiation between users...................................................................... 203
J.4 Low layer compatibility negotiation options ................................................................................ 204
J.5 Alternate requested values ............................................................................................................ 204
Annex K Procedures for establishment of bearer connection prior to call acceptance *......................... 205
Annex L Optional procedures for bearer service change * ...................................................................... 206
Appendix I

Definition of causes values............................................................................................. 207

Appendix II

Example message flow diagrams and example conditions for cause mapping * ........... 216

Appendix III

Summary of assigned information element identifier and message type code
points for the Q.93x-Series and Q.95x-Series of Recommendations ............................. 217

Appendix IV

Call procedure for the grouped multiple interfaces........................................................ 220

ACRONYMS USED IN THIS RECOMMENDATION............................................................................ 222* : This mark indicates sections which are specified in ITU-T Q.931 but are not included in this PHS MoU
specification.

B-IF2.02-02-TS

ix

LIST OF TABLESTABLE 7-1/IF2.01

Messages specific to supplementary service control

TABLE 7-2/IF2.01

FACILITY message content

TABLE 7-6/IF2.01

REGISTER message content

TABLE 8-1/IF2.01

IF2.01 message type

TABLE 8-2/IF2.01

Information elements specific to supplementary service control

TABLE 8-3/IF2.01

Call state information element

TABLE D-1/IF2.01

DTMF tone transmission operation (invoke)

TABLE D-2/IF2.01.

Handover operation

TABLE E-1/IF2.01

Error value used for the location registration operation

TABLE E-10/IF2.01

The ASN.1 module for the errors

TABLE E-2/IF2.01

Location registration operation (invoke)

TABLE E-3/IF2.01

Location registration operation (return result)

TABLE E-4/IF2.01

Error value used for the authentication operation

TABLE E-5/IF2.01

Authentication operation (invoke)

TABLE E-6/IF2.01

Authentication operation (return result)

TABLE E-7/IF2.01

Call clearing information notification operation (invoke)

TABLE E-8/IF2.01

Return error component

TABLE E-9/IF2.01

The ASN.1 module for the operationsx

B-IF2.02-02-TS

1. General
This specification specifies the procedures for the establishing, maintaining, and clearing of network
connections at the public cell station-ISDN interface. These procedures are defined in terms of
messages exchanged over the D-channel of basic and primary rate interface structures. The functions
and procedures of this protocol, and the relationship with other layers, are described in general termsin B-IF 2.00.
This specification is intended to specify the essential features, procedures, and messages required forcall control in the D-channel. However, there are some details of procedure which have not yet been
specified, and which will be the subject of further study.
1.1 Scope of the specification
The procedures currently described in this specification are for the control of circuit-switched. The
transport of other message-based information flows on the D-channel is a subject for further study.
Note 1: The term "layer 3" is used for the functions and protocol described in this specification. The
terms "data link layer" and "layer 2" are used interchangeably to refer to the layer
immediately below layer 3.
Note 2: Alignment of the functions and protocol with those of OSI network layer is for further study.
1.2 Application to interface structures
The layer 3 procedures apply to the interface structures defined in B-IF 2.00. They use the functions
and services provided by layer 2.
The layer 3 procedures request the services of layer 2 and receive information from layer 2 using theprimitives defined in layer 2 specification B-IF 2.03. These primitives are used to illustrate thecommunication between the protocol layers and are not intended to specify or constrain
implementations.

B-IF2.02-02-TS

1

2. Overview of call control
In this specification the terms "incoming" and "outgoing" are used to describe the call as viewed by
the public cell station side of the interface.
In the subclauses which follow states are defined for circuit switched calls in 2.1 (call states), and forthe interface in 2.4 (global call reference states).
This clause defines the basic call control states that individual calls may have. These definitions do
not apply to the state of the interface itself, any attached equipment, the D-channel, or the logical links
used for signalling on the D-channel. Because several calls may exist simultaneously at a public cellstation-ISDN interface, and each call may be in a different state, the state of the interface itself cannot
be unambiguously defined.
Note : Additional states and SDL diagrams may be defined when new procedures are developed.
A detailed description of the procedures for call control is given in clause 5 in terms of:(a) the messages defined in clause 3 which are transferred across the public cell station-ISDN
interface; and(b) the information processing and actions that take place at the public cell station side and the ISDN
side.
Overview and detailed SDL diagrams for call control of circuit-switched calls are contained in Annex
A.
Throughout this specification, references are made to B-channels.
2.1 Circuit switched calls
This subclause defines the basic call control states for circuit switched calls. The procedures for call
control are given in clause 5.
2.1.1 Call states at the public cell station side of the interface
The states which may exist on the public cell station side of the public cell station-ISDN interface aredefined in this subclause.
2.1.1.1 Null state (C0)No call exists.
2.1.1.2 Call initiated (C1)This state exists for an outgoing call, when the public cell station requests call establishment from the
ISDN.

2

B-IF2.02-02-TS2.1.1.3 Overlap sending (C2)*
2.1.1.4 Outgoing call proceeding (C3)This state exists for an outgoing call when the public cell station has received acknowledgement that
the ISDN has received all call information necessary to effect call establishment.
2.1.1.5 Call delivered (C4)This state exists for an outgoing call, when the calling public cell station has received an indicationthat remote side alerting has been initiated.
2.1.1.6 Call present (C6)This state exists for an incoming call when the public cell station has received a call establishment
request but has not yet responded.
2.1.1.7 Call received (C7)This state exists for an incoming call when the public cell station has indicated alerting but has not yet
answered.
2.1.1.8 Connect request (C8)This state exists for an incoming call when the public cell station has answered the call and is waiting
to be awarded the call.
2.1.1.9 Incoming call proceeding (C9)This state exists for an incoming call when the public cell station has sent acknowledgement that the
public cell station can proceed the call and has received all call information necessary to effect callestablishment.
2.1.1.10 Active (C10)This state exists for an incoming call when the public cell station has received an acknowledgementfrom the ISDN that the public cell station has been awarded the call. This state exists for an outgoingcall when the public cell station has received an indication that the remote side has answered the call.
2.1.1.11 Disconnect request (C11)This state exists when the public cell station has requested the ISDN to clear the end-to-end
connection (if any) and is waiting for a response.
2.1.1.12 Disconnect indication (C12)This state exists when the public cell station has received an invitation to disconnect because the
ISDN has disconnected the end-to-end connection (if any).

B-IF2.02-02-TS3

2.1.1.13 Suspend request (C15)*
2.1.1.14 Resume request (C17)*
2.1.1.15 Release request (C19)This state exists when the public cell station has requested the ISDN to release and is waiting for a
response.
2.1.1.16 Overlap receiving (U25)*
2.1.2 ISDN call states
The call states that may exist on the ISDN side of the public cell station-ISDN interface are defined inthis subclause.
2.1.2.1 Null state (N0)No call exists.
2.1.2.2 Call initiated (N1)This state exists for an outgoing call when the ISDN has received a call establishment request but has
not yet responded.
2.1.2.3 Overlap sending (N2)*
2.1.2.4 Outgoing call proceeding (N3)This state exists for an outgoing call when the ISDN has sent acknowledgement that the ISDN has
received all call information necessary to effect call establishment.
2.1.2.5 Call delivered (N4)This state exists for an outgoing call when the ISDN has indicated that remote side alerting has been
initiated.
2.1.2.6 Call present (N6)This state exists for an incoming call when the ISDN has sent a call establishment request but has not
yet received a satisfactory response.
2.1.2.7 Call received (N7)This state exists for an incoming call when the ISDN has received an indication that the public cellstation is alerting but has not yet received an answer.

4

B-IF2.02-02-TS2.1.2.8 Connect request (N8)This state exists for an incoming call when the ISDN has received an answer from the public cellstation but the ISDN has not yet awarded the call.
2.1.2.9 Incoming call proceeding (N9)This state exists for an incoming call when the ISDN has received acknowledgement that the public
cell station cann proceed the call and has received all call information necessary to effect callestablishment.
2.1.2.10 Active (N10)This state exists for an incoming call when the ISDN has awarded the call to the called public cellstation. This state exists for an outgoing call when the ISDN has indicated that the remote side has
answered the call.
2.1.2.11 Disconnect request (N11)This state exists when the ISDN has received a request from the public cell station to clear the end-toend connection (if any).
2.1.2.12 Disconnect indication (N12)This state exists when the ISDN has disconnected the end-to-end connection (if any) and has sent an
invitation to disconnect the public cell station-ISDN connection.
2.1.2.13 Suspend request (N15)*
2.1.2.14 Resume request (N17)*2.1.2.15 Release request (N19)This state exists when the ISDN has requested the public cell station to release and is waiting for a
response.
2.1.2.16 Call abort (N22)This state exists for an incoming call when the call is being cleared before any user has been awarded
the call.
2.1.2.17 Overlap receiving (N25)*
2.2 Packet-mode access connections *2.3 Temporary signalling connections *B-IF2.02-02-TS5

2.4 States associated with the global call referenceThis subclause defines the states that the protocol may adopt using the global call reference. The
procedures for use of the global call reference for RESTART are contained in 5.5.
There is only one global call reference per interface.
2.4.1 Call states at the public cell station side of the interface
The states which may exist on the public cell station side of the public cell station-ISDN interface aredefined in this subclause.
2.4.1.1 Null (Rest 0)
No transaction exists.
2.4.1.2 Restart request (Rest 1)
This state exists for a restart transaction when the public cell station has sent a restart request but has
not yet received an acknowledgement response from the ISDN.
2.4.1.3 Restart (Rest 2)
This state exists when a request for a restart has been received from the ISDN and responses have notyet been received from all locally active call references.
2.4.2 Call states at the ISDN side of the interface
The states which may exist on the ISDN side of the public cell station-ISDN interface are defined inthis subclause.
2.4.2.1 Null (Rest 0)
No transaction exists.
2.4.2.2 Restart request (Rest 1)
This state exists for a restart transaction when the ISDN has sent a restart request but has not yet
received an acknowledgement response from the public cell station.
2.4.2.3 Restart (Rest 2)
This state exists when a request for a restart has been received from the public cell station and a
response has not yet been received from all locally active call references.

6

B-IF2.02-02-TS

3. Message functional definitions and content
This subclause provides an overview of the Q.931 message structure, which highlights the functional
definition and information content (i.e. semantics) of each message. Each definition includes:a) A brief description of the message direction and use, including whether the message has:
1) Local significance, i.e. relevant only in the originating or terminating access;2) Access significance, i.e. relevant in the originating and terminating access, but not in the
ISDN;3) Dual significance, i.e. relevant in either the originating or terminating access and in the ISDN;
or4) Global significance, i.e. relevant in the originating and terminating access and in the ISDN.
b) A table listing the codeset 0 information elements in the order of their appearance in the message(same relative order for all message types). For each information element the table indicates:
1) the clause of this specification describing the information element;2) the direction in which it may be sent; i.e. public cell station to ISDN ("c o n"), ISDN to public
cell station ("n o c"), or both;3) whether inclusion is mandatory ("M") or optional ("O"), with a reference to Notes explaining
the circumstances under which the information element shall be included;4) the length of the information element (or permissible range of lengths), in octets, where "*"denotes an undefined maximum length, which may be network or service dependant;
Note : All messages may contain information elements from codesets 5, 6 and 7 and corresponding
locking and non-locking shift information elements which comply with the coding rules
specified in 4.5.4. None of these information elements, however, are listed in any of the tables
in clause 3;c) further explanatory Notes, as necessary.

B-IF2.02-02-TS

7

3.1 Messages for circuit mode connection control
Table 3-1 summarizes the messages for circuit-mode connection control.
Table 3-1/B-IF2.02(Q.931)
Messages for circuit-mode connection control
Reference(subclauses)
Call establishment messages:
ALERTING
CALL PROCEEDING
CONNECT
CONNECT ACKNOWLEDGE
PROGRESS
SETUP
Call clearing messages:
DISCONNECT
RELEASERELEASE COMPLETE
Miscellaneous messages:
NOTIFYSTATUSSTATUS ENQUIRY

3.1.1
3.1.2
3.1.3
3.1.4
3.1.8
3.1.143.1.5
3.1.9
3.1.103.1.7
3.1.163.1.173.1.1 ALERTING
This message is sent by the called public cell station to the ISDN and by the ISDN to the calling
public cell station, to indicate that called public cell station alerting has been initiated. See Table 3-2.
Table 3-2/B-IF2.02(Q.931)
ALERTING message content
Message type: ALERTING
Significance: global
Direction: both
Information element

Reference
Direction
Type
Length(subclause)
Protocol discriminator
4.2
Both
M
1
Call reference
4.3
Both
M
3
Message type
4.4
Both
M
1
Progress indicator
4.5.23n o c
O (Note)2-4Note: Included in the event of interworking. Included in the ISDN-to-public cell station direction inconnection with the provision of in-band information/patterns.

8

B-IF2.02-02-TS3.1.2 CALL PROCEEDING
This message is sent by the called public cell station to the ISDN or by the ISDN to the calling public
cell station to indicate that requested call establishment has been initiated and no more callestablishment information will be accepted. See Table 3-3.
Table 3-3/B-IF2.02(Q.931)
CALL PROCEEDING message content
Message type: CALL PROCEEDING
Significance: local
Direction: both
Information element

Reference
Direction
Type
Length(subclause)
Protocol discriminator
4.2
Both
M
1
Call reference
4.3
Both
M
3
Message type
4.4
Both
M
1
Channel identification
4.5.13Both
O (Note 1)
2-*
Progress indicator
4.5.23n o c
O (Note 2)
2-4
Note 1: Mandatory in the ISDN-to-public cell station direction if this message is the first message in response
to a SETUP message. It is mandatory in the public cell station-to-ISDN direction if this message is thefirst message in response to a SETUP message, unless the public cell station accepts the B-channel
indicated in the SETUP message.
Note 2: Included in the event of interworking. Included in the ISDN to public cell station direction inconnection with the provision of in-band information/patterns.

3.1.3 CONNECT
This message is sent by the called public cell station to the ISDN and by the ISDN to the calling
public cell station, to indicate call acceptance by the called public cell station. See Table 3-4.
Table 3-4/B-IF2.02(Q.931)
CONNECT message content
Message type: CONNECT
Significance: global
Direction: both
Information element

Reference
Direction
Type
Length(subclause)
Protocol discriminator
4.2
Both
M
1
Call reference
4.3
Both
M
3
Message type
4.4
Both
M
1
Progress indicator
4.5.23Both
O (Note 1)
2-4
Low layer compatibility
4.5.19Both
O (Note 2)
2-18
Note 1: Included in the event of interworking or in connection with the provision of in-band
information/patterns.
Note 2: Included in the public cell station-to-ISDN direction when the answering side wants to return low layercompatibility information to the calling side. Included in the ISDN-to-public cell station direction if
the called side awarded the call included a Low layer compatibility information element in the
CONNECT message. Optionally included for low layer compatibility negotiation, but some ISDNs
may not transport this information element to the calling side (see Annex J).

B-IF2.02-02-TS

9

3.1.4 CONNECT ACKNOWLEDGE
This message is sent by the ISDN to the called public cell station to indicate the public cell station has
been awarded the call. It may also be sent by the calling public cell station to the ISDN to allow
symmetrical call control procedures. See Table 3-5.
Table 3-5/B-IF2.02(Q.931)
CONNECT ACKNOWLEDGE message content
Message type: CONNECT ACKNOWLEDGE
Significance: local
Direction: both
Information element
Protocol discriminator
Call reference
Message type

Reference(subclause)
4.2
4.3
4.4

Direction

Type

Length

Both
Both
Both

M
M
M

1
3
1

3.1.5 DISCONNECT
This message is sent by the public cell station to request the ISDN to clear an end-to-end connection
or is sent by the ISDN to indicate that the end-to-end connection is cleared. See Table 3-6.
Table 3-6/B-IF2.02(Q.931)
DISCONNECT message content
Message type: DISCONNECT
Significance: global
Direction: both
Information element

Reference
DirectionType(subclause)
Protocol discriminator
4.2
Both
M
Call reference
4.3
Both
M
Message type
4.4
Both
M
Cause
4.5.12
Both
M
Progress indicator
4.5.23(Note 1)O (Note 2)
Note 1: Included in the ISDN-to-public cell station direction if the ISDN provides in-band tones.
Note 2: Included by the ISDN if in-band tones are provided.

3.1.6 INFORMATION*

10

B-IF2.02-02-TS

Length
1
3
1
4-32
2-4

3.1.7 NOTIFY
This message is sent by the ISDN to indicate information pertaining to a call, such as user suspended.
See Table 3-8.
Table 3-8/B-IF2.02(Q.931)
NOTIFY message content
Message type: NOTIFY
Significance: accessDirection: n o cInformation element

Reference(subclause)

Direction

Type

LengthProtocol discriminator
Call reference
Message type

4.2
4.3
4.4

n o c
n o c
n o c

M
M
M

1
3
1

Notification indicator

4.5.22

n o c

M

3

3.1.8 PROGRESSThis message is sent by the public cell station or the ISDN to indicate the progress of a call in theevent of interworking or in relation with the provision of in-band information/patterns. See Table 3-9.
Table 3-9/B-IF2.02(Q.931)
PROGRESS message content
Message type: PROGRESS
Significance: global
Direction: both
Information element

Reference
Direction
Type
Length(subclause)
Protocol discriminator
4.2
Both
M
1
Call reference
4.3
Both
M
3
Message type
4.4
Both
M
1
Cause
4.5.12BothO (Note)2-32
Progress indicator
4.5.23
Both
M
4
Note: Included by the public cell station or the ISDN to provide additional information concerning theprovision of in-band information/patterns.

B-IF2.02-02-TS

11

3.1.9 RELEASE
This message is sent by the public cell station or the ISDN to indicate that the equipment sending themessage has disconnected the channel (if any) and intends to release the channel and the callreference. Thus the receiving equipment should release the channel and prepare to release the callreference after sending a RELEASE COMPLETE. See Table 3-10.
Table 3-10/B-IF2.02(Q.931)
RELEASE message content
Message type: RELEASE
Significance: local (Note 1)
Direction: both
Information element

Reference
Direction
Type
Length(subclause)
Protocol discriminator
4.2
Both
M
1
Call reference
4.3
Both
M
3
Message type
4.4
Both
M
1
Cause
4.5.12BothO (Note 2)
2-32
Note 1: This message has local significance; however, it may carry information of global significance when usedas the first call clearing message.
Note 2: Mandatory in the first call clearing message, including when the RELEASE message is sent as a resultof an error handling condition.

3.1.10 RELEASE COMPLETE
This message is sent by the public cell station or the ISDN to indicate that the equipment sending themessage has released the channel (if any) and call reference, the channel is available for reuse, and thereceiving equipment shall release the call reference. See Table 3-11.
Table 3-11/B-IF2.02(Q.931)
RELEASE COMPLETE message content
Message type: RELEASE COMPLETE
Significance: local (Note 1)
Direction: both
Information element

Reference
Direction
Type
Length(subclause)
Protocol discriminator
4.2
Both
M
1
Call reference
4.3
Both
M
3
Message type
4.5
Both
M
1
Cause
4.5.12BothO (Note 2)
2-32
Note 1: This message has local significance; however, it may carry information of global significance whenused as the first call clearing message.
Note 2: Mandatory in the first call clearing message, including when the RELEASE COMPLETE message issent as a result of an error handling condition.

12

B-IF2.02-02-TS3.1.11 RESUME*
3.1.12 RESUME ACKNOWLEDGE*
3.1.13 RESUME REJECT*
3.1.14 SETUPThis message is sent by the calling public cell station to the ISDN and by the ISDN to the called
public cell station to initiate call establishment. See Table 3-15.
Table 3-15/B-IF2.02(Q.931)
SETUP message content
Message type: SETUP
Significance: global
Direction: both
Information element

Reference
Direction
Type
Length(subclause)
Protocol discriminator
4.2
Both
M
1
Call reference
4.3
Both
M
3
Message type
4.4
Both
M
1
Bearer capability
4.5.5
Both
M
4-10
Channel identification
4.5.13Both
O (Note 1)
2-*
Progress indicator
4.5.23Both
O (Note 2)
2-4
Calling party number
4.5.10BothO (Note 3)
2-*
Calling party subaddress
4.5.11BothO (Note 4)
2-23
Called party number
4.5.8
Both
M
2-*
Called party subaddress
4.5.9
Both
O (Note 5)
2-23
Repeat indicator
4.5.24Both
O (Note 6)
1
Low layer compatibility
4.5.19Both
O (Note 7)
2-18
High layer compatibility
4.5.17Both
O (Note 8)
2-5
Note 1: Mandatory in the ISDN-to-public cell station direction. Included in the public cell station-to-ISDN
direction when a public cell station wants to indicate a channel. If not included, its absence isinterpreted as "any channel acceptable".
Note 2: Included in the event of interworking or in connection with the provision of in-band
information/patterns.
Note 3: May be included by the calling side or the ISDN to identify the calling side. May not be included in the
ISDN-to-public cell station direction for basic call control. Mandatory in the public cell station-toISDN direction.
Note 4: Included in the public cell station-to-ISDN direction when the calling side wants to indicate the calling
party subaddress. May be included in the ISDN-to-public cell station direction for basic call.
Note 5: Included in the public cell station-to-ISDN direction when the calling public cell station wants toindicate the called party subaddress. Included in the ISDN-to-public cell station direction if a Called
party subaddress information element is included in the SETUP message.
Note 6: Included when two or more Low layer compatibility information elements are included for low layercompatibility negotiation.
Note 7: Included in the public cell station-to-ISDN direction when the calling side wants to pass low layercompatibility information to the called side. Included in the ISDN-to-public cell station direction if thecalling side included a Low layer compatibility information element in the SETUP message. Two, threeor four information elements may be included in descending order of priority, i.e. highest priority first,
if the low layer compatibility negotiation procedures are used (see Annex J).
Note 8: Included in the public cell station-to-ISDN direction when the calling side wants to pass high layercompatibility information to the called side. Included in the ISDN-to-public cell station direction if thecalling side included a High layer compatibility information element in the SETUP message.

B-IF2.02-02-TS

13

3.1.15 SETUP ACKNOWLEDGE*

3.1.16 STATUS
This message is sent by the public cell station or the ISDN in response to a STATUS ENQUIRY
message or at any time during a call to report certain error conditions listed in 5.8. See Table 3-17.
Table 3-17/B-IF2.02(Q.931)
STATUS message content
Message type: STATUS
Significance: local
Direction: both
Information element
Protocol discriminator
Call reference
Message type
Cause
Call state

Reference(subclause)
4.2
4.3
4.4
4.5.12
4.5.7

Direction

Type

Length

Both
Both
Both
Both
Both

M
M
M
M
M

1
3
1
4-32
3

3.1.17 STATUS ENQUIRYThis message is sent by the public cell station or the ISDN at any time to solicit a STATUS message
from the peer layer 3 entity. Sending a STATUS message in response to a STATUS ENQUIRY
message is mandatory. See Table 3-18.
Table 3-18/B-IF2.02(Q.931)
STATUS ENQUIRY message content
Message type: STATUS ENQUIRY
Significance: local
Direction: both
Information element
Protocol discriminator
Call reference
Message type

Reference(subclause)
4.2
4.3
4.4

3.1.18 SUSPEND*
3.1.19 SUSPEND ACKNOWLEDGE*
3.1.20 SUSPEND REJECT*
3.2 Messages for packet mode connection control *3.3 Messages for user signalling bearer sevice control *14

B-IF2.02-02-TS

Direction

Type

Length

Both
Both
Both

M
M
M

1
3
1

3.4 Messages with the global call reference
Table 3-48 summarizes the messages which may use the global call reference defined in 4.3.
Table 3-48/B-IF2.02(Q.931)
Messages used with the global call reference
Messages
RESTARTRESTART ACKNOWLEDGE
STATUS

Reference(subclause)
3.4.1
3.4.2
3.4.3

3.4.1 RESTART
This message is sent by the public cell station or ISDN to request the recipient to restart (i.e. return toan idle condition) the indicated channel(s) or interface. See Table 3-49.
Table 3-49/B-IF2.02(Q.931)
RESTART message content
Message type: RESTART
Significance: local
Direction: both
Information element

Reference
Direction(subclause)
Protocol discriminator
4.2
Both
Call reference
4.3
Both
Message type
4.4
Both
Channel identification
4.5.13
Both
Restart indicator
4.5.25
Both
Note 1: This message is sent with the global call reference defined in 4.3.
Note 2: Included when necessary to indicate the particular channel(s) to be restarted.

Type

LengthM
M (Note 1)
M
O (Note 2)
M

1
3
1
2-*
3

B-IF2.02-02-TS

15

3.4.2 RESTART ACKNOWLEDGE
This message is sent to acknowledge the receipt of the RESTART message and to indicate that therequested restart is complete. See Table 3-50.
Table 3-50/B-IF2.02(Q.931)
RESTART ACKNOWLEDGE message content
Message type: RESTART ACKNOWLEDGE
Significance: local
Direction: both
Information element

Reference
DirectionType(subclause)
Protocol discriminator
4.2
Both
M
Call reference
4.3
Both
M (Note 1)
Message type
4.4
Both
M
Channel identification
4.5.13Both
O (Note 2)
Restart indicator
4.5.25Both
M
Note 1: This message is sent with the global call reference defined in 4.3.
Note 2: Included when necessary to indicate the particular channel(s) which have been restarted.

Length13
1
2-*
3

3.4.3 STATUS
This message is sent by the public cell station or the ISDN at any time during a call to report certain
error conditions listed in 5.8 See Table 3-51
Table 3-51/B-IF2.02(Q.931)
STATUS message content
Message type: STATUS
Significance: local
Direction: both
Information element

Reference
Direction(subclause)
Protocol discriminator
4.2
Both
Call reference
4.3
Both
Message type
4.4
Both
Cause
4.5.12
Both
Call state
4.5.7
Both
Note 1: This message may be sent with the global call reference defined in 4.3.

16

B-IF2.02-02-TS

Type

LengthM
M (Note 1)
M
M
M

1
3
1
4-32
3

4. General message format and information elements coding
The figures and text in this clause describe message contents. Within each octet, the bit designated "bit1" is transmitted first, followed by bits 2, 3, 4, etc. Similarly, the octet shown at the top of each figure
is sent first.
4.1 Overview
Within this protocol, every message shall consist of the following parts:
a)
b)
c)
d)

protocol discriminator;
call reference;message type;other information elements, as required.

Information elements a), b) and c) are common to all the messages and shall always be present, while
information element d) is specific to each message type.
This organization is illustrated in the example shown in Figure 4-1.
A particular message may contain more information than a particular (public cell station or digital
network) equipment needs or can understand. All equipment should be able to ignore any extra
information, present in a message, which is not required for the proper operation of that equipment.
For example, a public cell station may ignore the calling party number if that number is of no interest
to the user when a SETUP message is received.
Bit
8

7

0

0

0

6

5
4
3
2
1
Protocol discriminator00
Length of call reference value(in octets)
Call reference value
Message type
Other information elements as required

Octets123
etc.

Figure 4-1/B-IF2.02(Q.931)
General message organization example

Unless specified otherwise, a particular information element may be present only once in a given
message.
The term "default"implies that the value defined should be used in the absence of any assignment, orthe negotiation of alternative values.
When a field, such as the call reference value, extends over more than one octet, the order of bit
values progressively decreases as the octet number increases. The least significant bit of the field isrepresented by the lowest numbered bit of the highest-numbered octet of the field.

B-IF2.02-02-TS

17

4.2 Protocol discriminator
The purpose of the protocol discriminator is to distinguish messages for user-network call control
from other messages (to be defined). It also distinguishes messages of this Standard from those OSI
network layer protocol units which are coded to other ITU-T Recommendations and other standards.
The protocol discriminator is the first part of every message. The protocol discriminator is coded
according to Table 4-1.

8
0

Bit
7
6
5
4
3
2
Q.931/I.451 public cell station -digital network call control messages
1
0
0
0
1
1
Protocol discriminator

1

Octet

0

1

Figure 4-2/B-IF2.02(Q.931)
Protocol discriminator

The value of the protocol discriminator is based on the figure 4-1/B-IF2.02(Q.931).
Table 4-1/B-IF2.02(Q.931)
Protocol discriminator
8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0•
0 0 0 0 0 1 1 1
0 0 0 0 1 0 0 0
0 0 0 1 0 0 0 0•
0 0 1 1 1 1 1 1
0 1 0 0 0 0 0 0
0 1 0 0 0 0 0 1
0 1 0 0 0 0 1 0
0 1 0 0 0 0 1 1
0 1 0 0 0 1 0 0
0 1 0 0 0 1 0 1
0 1 0 0 0 1 1 0
0 1 0 0 0 1 1 1•
0 1 0 0 1 1 1 1
0 1 0 1 0 0 0 0•

Assigned in subclause 4.5.30; not available for use in the message
protocol discriminator
Recommendation Q.931/I.451 user-network call control messages
Reserved for other network layer or layer 3 protocols, including
Recommendation X.25 (Note)
National use
National use. Assigned in subclause 4.5.30; not available for use in themessage protocol discriminator
National use. PBX-PBX digital interface, common channel signaling
system.
RCR STD-28 radio control message on radio section
RCR STD-28 mobility control message on radio section
RCR STD-28 call control message on radio section
Recommendation Q.931 public cell station - digital network call control
messages
National use
Reserved for other network layer or layer 3 protocols, including
Recommendation X.25 (Note)

1 1 1 1 1 1 1 0
All other values are reserved.
Note : These values are reserved to discriminate these protocol discriminators from the first octet of a
Recommendation X.25 packet including general format identifier.

18

B-IF2.02-02-TS

4.3 Call reference
The purpose of the call reference is to identify the call or facility registration/cancellation request at
the local public cell station-digital network interface to which the particular message applies. The callreference does not have end-to-end significance across ISDNs.
The call reference is the second part of every message. The call reference is coded as shown in Figure
4-3. The length of the call reference value is indicated in octet 1, bits 1-4. The default maximum
length of the call reference information element is three octets long. The actions taken by the receiverare based on the numerical value of the call reference and are independent of the length of the callreference information element.
All digital networks and public cell station must be able to support a call reference value of two octets.
The call reference information element includes the call reference value and the call reference flag.
Call reference values are assigned by the originating side of the public cell station-digital network
interface for a call. These values are unique to the originating side only within a particular D-Channel
layer two logical link connection. The call reference value is assigned at the beginning of a call andremains fixed for the lifetime of a call (except in the case of call suspension). After a call ends, theassociated call reference value may be reassigned to a later call. Two identical call reference values on
the same D-Channel layer two logical link connection may be used when each value pertains to a calloriginated at opposite ends of the link.

Bit
8
0

7
0

6
0

5
0

4

3
2
1
Length of call reference value(in octets)

Octets
1

Flag

2
etc.

Call reference value
call reference flag (octet 2):
bit 8
0 the message is sent from the side that originate the call reference.
1 the message is sent to the side that originates the call reference.
Figure 4-3/B-IF2.02(Q.931)
Call reference information element

The call reference flag can take the values "0" or "1". The call reference flag is used to identify which
end of the layer two logical link originated a call reference. The origination side always sets the callreference flag to "0". The destination side always sets the call reference flag to a "1".
Hence the call reference flag identifies who allocated the call reference value for this call and the only
purpose of the call reference flag is to resolve simultaneous attempts to allocate the same callreference value.

B-IF2.02-02-TS

19

The call reference flag also applies to functions which use the global call reference (e.g. restart
procedures).
Note : The numerical value of the global call reference is zero. The equipment receiving a message
containing the global call reference should interpret the message as pertaining to all callreferences associated with the appropriate data link connection identifier. See Figure 4-5.
Bit
8

7

6

0

0

0

0/1
Flag
0

0

0

0

0

5

4

3
2
Length of call0001
Reference value0000Call reference value
0
0
0
0

1

Octets

0

1

0

2

0

3

b) Two octet call reference value
Figure 4-5/B-IF2.02(Q.931)
Exemples of the encoding for global call reference

4.4 Message type
The purpose of the message type is to identify the function of the message being sent.
The message type is the third part of every message. The message type is coded as shown in Figure 46 and Table 4-2.
Bit 8 is reserved for possible future use as an extension bit.
Bit
8
0

7

6

5

4
Message type3

Figure 4-6/B-IF2.02(Q.931)
Message type20

B-IF2.02-02-TS

2

1

Octet
1

Table 4-2/B-IF2.02(Q.931)
Message types
Bit
8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0
0 0 0 - - - - 0 0 0 0 1
0 0 0 1 0
0 0 1 1 1
0 1 1 1 1
0 0 0 1 1
0 0 1 0 1
0 1 0 - - - - 0 0 1 0 1
0 1 1 0 1
1 1 0 1 0
0 0 1 1 0
0 1 1 1 0
0 1 1 - - - - 0 0 0 0 0
0 1 1 1 0
1 1 1 0 1
1 0 1 0 1

Note :

Escape to nationally specific message type (Note)
Call establishment message:- ALERTING- CALL PROCEEDING- CONNECT- CONNECT ACKNOWLEDGE- PROGRESS- SETUP
Call clearing messages:- DISCONNECT- RELEASE- RELEASE COMPLETE- RESTART- RESTART ACKNOWLEDGE
Miscellaneous messages:- SEGMENT- NOTIFY- STATUS- STATUS ENQUIRYWhen used, the message type is defined in the following octet(s), according to the national
specification.

B-IF2.02-02-TS

21

4.5 Other information elements
4.5.1 Coding rules
The coding of other information elements follows the coding rules described below. These rules areformulated to allow each equipment which processes a message to find information elements
important to it, and yet remain ignorant of information elements not important to that equipment.
Two categories of information elements are defined:(1) single octet information elements (see diagrams a) and b) of Figure 4-7);(2) variable length information elements (see diagram c) of Figure 4-7).

Bit
8
1

7

6
5
Information element
identifier

4

3
2
Contents of information
element

1

Octet
1

1

Octet
1

1

Octet
1
2
3
etc.

a) Single octet information element format (type 1)

8
1

7

6

Bit
5
4
3
Information element identifier

2b) Single octet information element format (type 2)

8
1

7

Bit
5
4
3
Information element identifier
Length of contents of information element (octets)
Contents of information element
62c) Variable length information element format
Figure 4-7/B-IF2.02(Q.931)
Formats of information elements

For the information elements listed below, the coding of the information element identifier bits issummarized in Table 4-3.

22

B-IF2.02-02-TS

Table 4-3/B-IF2.02(Q.931)
Information element identifier coding
Bit
Reference(subclause)

MaximumLength(octets)(Note 1)8 7 6 5 4 3 2 1(octet)1 : : : - - - Single octet informaiton elements:(note1)0 0 0 - - - Reserved
1
4.5.3/4.5.4
0 0 1 - - - Shift (Note 2)(non-standard)0 1 0 0 0 0 0More data(non-standard)0 1 0 0 0 0 1
Sending complete(non-standard)
0 1 1 - - - Congestion level1
4.5.241 0 1 - - - Repeat indicator
0 : : : : : : :Variable length information element:
4.5.260 0 0 0 0 0 0
Segmented message
54.5.5
0 0 0 0 1 0 0
Bearer capability
32
4.5.120 0 0 1 0 0 0
Cause (Note 2)(non-standard)
0 0 1 0 0 0 0Call identity
3
4.5.7
0 0 1 0 1 0 0
Call state(Note 4)4.5.130 0 1 1 0 0 0Channel identification•
4.5.230 0 1 1 1 1 0
Progress indicator (Note 2)(non-standard)0 1 0 0 0 0 0
Network-specific facilities3
4.5.220 1 0 0 1 1 1
Notification indicator(non-standard)0 1 0 1 0 0 0
Display(non-standard)0 1 0 1 0 0 1
Date/time(non-standard)0 1 0 1 1 0 0
Keypad facility(non-standard)
0 1 1 0 1 0 0
Signal(non-standard)
1 0 0 0 0 0 0
Information rate(non-standard)
1 0 0 0 0 1 0
End-to-end transit delay(non-standard)
1 0 0 0 0 1 1Transit delay selection and indication(non-standard)
1 0 0 0 1 0 0
Packet layer binary parameters(non-standard)
1 0 0 0 1 0 1
Packet layer window size
(non-standard)
1 0 0 0 1 1 0
Packet size
(non-standard)
1 0 0 0 1 1 1
Closed user group(non-standard)
1 0 0 1 0 1 0
Reverse charge indication(Note 4)4.5.101 1 0 1 1 0 0
Calling party number
23
4.5.111 1 0 1 1 0 1
Calling party subaddress(Note 4)4.5.8
1 1 1 0 0 0 0
Called party number
23
4.5.9
1 1 1 0 0 0 1
Called party subaddress(non-standard)
1 1 1 0 1 0 0
Redirecting number(non-standard)
1 1 1 1 0 0 0Transit network selection
3
4.5.251 1 1 1 0 0 1
Restart indicator184.5.191 1 1 1 1 0 0
Low layer compatibility(Note2)
54.5.171 1 1 1 1 0 1High layer compatibility(non-standard)
1 1 1 1 1 1 0
User-user
1 1 1 1 1 1 1
Escape for extension (Note 3)
All other values are reserved (Note 5)
Note 1: The length limits described for the variable length information elements take into account only thepresent CCITT standardized coding values. Future enhancements and expansions to thisRecommendation will not be restricted to these limits.
Note 2: This information element may be repeated.
Note 3: This escape mechanism is limited to codesets 4, 5, 6 and 7 (see 4.5.2). When the escape for extension isused, the information element identifier is contained in octet-group 3 and the content of the information
element follows in the subsequent octets as shown in Figure 4-8.
Note 4: The maximum length is digital network dependent.
Note 5: The reserved values with bits 5-8 coded "0000" are for future information elements for which
comprehension by the receiver is required (see 5.8.7.1).

B-IF2.02-02-TS

23

There is a particular order of appearance for each information element in a message within eachcodeset. The code values of the information element identifier for the variable length formats are
assigned in ascending numerical order, according to the actual order of appearance of each
information element in a message. This allows the receiving equipment to detect the presence orabsence of a particular information element without scanning through an entire message.
Single octet information elements may appear at any point in the message. Two types of single octet
information elements have been defined. Type 1 elements provide the information element
identification in bit positions 7, 6, 5. The value "010" in these bit positions is reserved for Type 2
single octet elements.
Where the description of information elements in this Recommendation contains spare bits, these bits
are indicated as being set to "0". In order to allow compatibility with future implementation, messages
should not be rejected simply because a spare bit is set to "1".
The second octet of a variable length information element indicates the total length of the contents ofthat information element regardless of the coding of the first octet (i.e. the length starting with octet3). It is the binary coding of the number of octets of the contents, with bit 1 as the least significant bit(2• ).
An optional variable-length information element may be present, but empty. For example, a SETUP
message may contain a called party number information element, the content of which is of zero
length. This should be interpreted by the receiver as equivalent to that information element being
absent. Similarly, an absent information element should be interpreted by the receiver as equivalent tothat information element being empty.
The following rules apply for the coding of variable length information elements (octets 3, etc.):a) The first digit in the octet number identifies one octet or a group of octets.
b) Each octet group is a self contained entity. The internal structure of an octet group may be definedin alternative ways.
c) An octet group is formed by using some extension mechanism. The preferred extension
mechanism is to extend an octet (N) through the next octet(s) (Na, Nb, etc.) by using bit 8 in eachoctet as an extension bit. The bit value "0" indicates that the octet continues through the next octet.
The bit value "1" indicates that this octet is the last octet. If one octet (Nb) is present, also thepreceding octets (N and Na) must be present.
In the format descriptions appearing in 4.5.5 etc., bit 8 is marked "0/1 ext," if another octet
follows. Bit 8 is marked "1 ext," if this is the last octet in the extension domain.
Additional octets may be defined later ("1 ext." changed to "0/1 ext.") and equipments shall be
prepared to receive such additional octets although the equipment need not be able to interpret or
act upon the content of these octets.
d) In addition to the extension mechanism defined above, an octet (N) may be extended through thenext octet(s) (N1, N2 etc.) by indications in bits 7-1 (of octet N).
e) The mechanisms in c) and d) may be combined. Mechanism c) shall take priority in the ordering,24

B-IF2.02-02-TS

such that all octets Na, Nb, etc. shall occur before octets N1, N2, etc. This rule shall apply even
where the extension to octets N1, N2, etc. is indicated in one of octet Na, Nb, etc.
f) Similar conventions apply even when mechanism d) is being repeated, i.e. octets N.1 shall occur
before octets N.1.1, N.1.2, etc.
g) Optional octets are marked with asterisks (*).
Note 1: It is not possible to use mechanism c) repeatedly, i.e. it is not possible to construct an octet 4a
as this would become octet 4b.
Note 2: Protocol designers should exercise care in using multiple extension mechanisms to ensurethat a unique interpretation of the resultant coding is possible.
Note 3: For a number of information elements there is a field that defines the coding standard. Whenthe coding standard defines a national standard it is recommended that the national standard
be structured similar to the information element defined in this Recommendation.
Bit
8

7

0

1

1 ext.

65

4
3
Escape for extension
1
1
1
1
Length of information element contents 2
Information element identifier
Contents of information element

2

1

Octet

1

1

1
2
3
4
etc.

Figure 4-8/B-IF2.02(Q.931)
Information element format using escape for extension
4.5.2 Extensions of codesets
There is a certain number of possible information element identifier values using the formatting rules
described in 4.5.1; 128 from the variable length information element format and at least 8 from thesingle octet information element format.
One value in the single octet format is specified for shift operations described below. One other value
in both the single octet and variable format is reserved. This leaves at least 133 information element
identifier values available for assignment.
It is possible to expand this structure to eight codesets of at least 133 information element identifier
values each. One common value in the single octet format is employed in each codeset to facilitate
shifting from one codeset to another. The contents of this Shift information element identifies thecodeset to be used for the next information element or elements. The codeset in use at any given timeis referred to as the "active codeset". By convention, codeset 0 is the initially active codeset.
Two codeset shifting procedures are supported: locking shift and non-locking shift.
Codeset 4 is reserved for use by ISO/IEC standards.

B-IF2.02-02-TS

25

Codeset 5 is reserved for information elements reserved for national use.
Codeset 6 is reserved for information elements specific to the local network (either public or private).
Codeset 7 is reserved for user-specific information elements.
The coding rules specified in 4.5.1 shall apply for information elements belonging to any active
codeset.
Transitions from one active codeset to another (i.e. by means of the locking shift procedure) may only
be made to a codeset with a higher numerical value than the codeset being left.
An information element belonging to codesets 4, 5, 6, or 7, may appear together with information
elements belonging to codeset 0 (being the active codeset) by using the non-locking shift procedure(see 4.5.4).
The public cell station or digital network shall have the capability to recognize a Shift information
element and to determine the length of the following information element, although the equipment
need not be able to interpret and act upon the content of the information element. This enables theequipment to determine the start of a subsequent information element.
Codeset 7 information element shall be handled according to the procedures for unrecognized
information elements (see 5.8.7.1) by the first exchange in the local network, unless allowed by afuture service definition, bilateral agreement, or provision is made to support this across the local
digital network for a specific public cell station.
Codeset 6 is reserved for information elements specific to the local digital network (either public or
private). As such they do not have significance across the boundaries between local digital networks,
or across a national, or international boundary. Therefore, codeset 6 information elements shall behandled according to the procedures for unrecognized information elements (see 5.8.7.1) beyond local
network boundary, unless allowed by bilateral agreement.
Codeset 5 is reserved for information elements reserved for national use. As such they do not havesignificance across an international boundary. Therefore, codeset 5 information elements shall behandled according to the procedures for unrecognized information elements (see 5.8.7.1) at the firstexchange beyond the international boundary, unless there are bilateral agreements to the contrary.
Codeset 4 is reserved for information elements specified in ISO/IEC standards.
4.5.3 Locking shift procedure
The locking shift procedure employs an information element to indicate the new active codeset. The
specified codeset remains active until another locking shift information element is encountered which
specifies the use of another codeset. For example, codeset 0 is active at the start of message content
analysis. If a locking shift to codeset 5 is encountered, the next information elements will beinterpreted according to the information element identifiers assigned in codeset 5, until another shift
information element is encountered.

26

B-IF2.02-02-TS

This procedure is used only to shift to a higher order codeset than the one being left.
The locking shift is valid only within that message which contains the locking Shift information
element. At the start of every message content analysis, the active codeset is codeset 0.
The locking Shift information element uses the single octet information element format and codingshown in Figure 4-9 and Table 4-4.
4.5.4 Non-locking shift procedure
The non-locking shift procedure provides a temporary shift to the specified lower or higher codeset.
The non-locking shift procedure uses a single octet information element to indicate the codeset to be
used to interpret the next single information element. After the interpretation of the next single
information element, the active codeset is again used for interpreting any following information
elements. For example, codeset 0 is active at the beginning of message content analysis. If a nonlocking shift to codeset 6 is encountered, only the next information element is interpreted according to
the information element identifiers assigned in codeset 6. After this information element is interpreted,codeset 0 will again be used to interpret the following information elements. A non-locking Shift
information element indicating the current codeset shall not be regarded as an error.
Bit
8

7

1

0

6
Shift
0

5

4

1

0

3

2

1

Octet

New condeset
Identification

1

identifiern"0" in this positionindicates locking shift
Figure 4-9/B-IF2.02(Q.931)
Locking Shift information element

B-IF2.02-02-TS

27

Table 4-4/B-IF2.02(Q.931)
Locking Shift information element
Codeset identification (bits 3 to 1):
Bit
3 2 1
0 0 0
Not applicable
0 0 1 ½
to,
¾ Reserved
0 1 1 ¿
1 0 0
Codeset 4: information elements for ISO/IEC use
1 0 1
Codeset 5: information elements for national use (note)
1 1 0
Codeset 6: information elements specific to the local network (either public or private)1 1 1
Codeset 7: user-specific information elements

A locking Shift information element shall not follow directly on a non-locking Shift information
element. If this combination is received, it shall be interpreted as though a locking Shift information
element only had been received.
The non-locking Shift information element uses the single octet information element format andcoding shown in Figure 4-10 and Table 4-5.
Bit
8

7

1

0

6
Shift
0
identifier

5

4

1

1

3

2

1

New condeset
Identificationn"1" in this positionindicates non-locking shift
Figure 4-10/B-IF2.02(Q.931)
Non-locking Shift information element

Table 4-5/B-IF2.02(Q.931)
Non-locking Shift information element
Codeset identification (bits 3 to 1):
Bit
3 2 1
0 0 0
Codeset 0 (initially active): Q.931 information elements
0 0 1
to Reserved
0 1 1
1 0 0
Codeset 4: information elements for ISO/IEC use
1 0 1
Codeset 5: information elements for national use
1 1 0
Codeset 6: information elements specific to the local network (either public or
private)1 1 1
Codeset 7: user-specific information elements

28

B-IF2.02-02-TS

Octet
1

4.5.5 Bearer capability
The purpose of the Bearer capability information element is to indicate a requested Recommendation
I.231 [6] bearer service to be provided by the digital network. It contains only information which may
be used by the digital network (see Annex I).
The use of the Bearer capability information element in relation to compatibility checking is describedin Annex B.
The Bearer capability information element is coded as shown in Figure 4-11 and Table 4-6.
No default bearer capability may be assumed by the absence of this information element.
The maximum length of this information element is 12 octets.

80

1 ext.
1 ext.
1 ext.
0/1 ext.
0/1 ext.
0/1 ext.
0/1 ext.
0/1 ext.
1 ext.

Bit
7
6
5
4
3
2
Bearer capability
0
0
0
0
1
0
Information element identifier
Length of the bearer capability contents
Coding standard
Information transfer capability
Transfer mode
Information transfer rate
Rate multiplier01
Layer 1
ident.
Synch./
Negot.
asynchIntermediate rate
Hdr/ no
Multi
Hdr
frame
Number of stop bits
Duplexmode

1

Octets

0

1
2
3
4
4.1*
(Note 1)
5*

User information layer 1
protocolUser rate
NIC onTx

NIC onRx

Flowcontrol
on Tx

LLI
negot.
Number of data bits

A ssig n or/e e

Mode

Flow
control
on Rx
In-bandneg.
ParityModem type0 Spare0 Spare5a*(Note 2)5b*(Note 3)5b*(Note 4)5c*(Note 2)5d*(Note 2)

Note 1: This octet is required if octet 4 indicates multirate (64 kbit/s base rate). Otherwise, it shall not
be present.
Note 2: This octet may be present if octet 3 indicates unrestricted digital information and octet 5
indicates either of the ITU-T standardized rate adaptions V.110 and X.30 or V.120 [9]. It may
also be present if octet 3 indicates 3.1 kHz audio and octet 5 indicates G.711.
Note 3: This octet is significant only if octet 5 indicates ITU-T standardized rate adaption (seeRecommendation V.110 [7] and X.30 [8]Note 4: This octet is significant only if octet 5 indicates ITU-T standardized rate adaption see
Recommendation V.120 [9].
Figure 4-11/B-IF2.02(Q.931)
Bearer capability information element

B-IF2.02-02-TS

29

Table 4-6/B-IF2.02(Q.931)
Bearer capability information element
Coding standard (octet 3)
Bit
7 6
0 0
0 1
1 0
1 1

ITU-Tstandardized coding as described below
ISO/IEC standard (Note1)
National standard (Note1)
Standard defined for the network (either public or private) present on the network side of
the interface(Note)

Note 1: These other coding standards should be used only when the desired bearer capability
cannot be represented with theITU-T-standardized coding.
Information transfer capability (octet 3)
Bit
5 4 3 2 1
0 0 0 0 0 Speech0 1 0 0 0 Unrestricted digital information
0 1 0 0 1 Restricted digital information
1 0 0 0 0 3.1 kHz audio
1 0 0 0 1 Unrestricted digital information with tones/announcements
1 1 0 0 0 Video
All other values are reserved.
Transfer mode (octet 4)
Bit
7 6
0 0
Circuit mode
1 0
Packet mode (note)
All other values are reserved.
(note) The use of this code is a subject in future.
Information transfer rate (octets 4)Bit
5 4 3 2 1 Circuit mode0 0 0 0 0 This code shall be used for packet mode calls(note3)
1 0 0 0 0 64 kbit/s
1 0 0 0 1 2 u 64 kbit/s
1 0 0 1 1 384 kbit/s
1 0 1 0 1 1536 kbit/s
1 0 1 1 1 1920 kbit/s
1 1 0 0 0 Multirate (64 kbit/s base rate)
All other values are reserved.
Note 1: When the information transfer rate 2 u 64 kbit/s is used, the coding of octets 3 and 4 refer
to both 64 kbit/s channels.
Note 2: Additional attributes are defined in Table 4-7.
Note 3: The use of this code is a subject in future.
Rate mutiplier (octet 4.1)
Note 4: Coded as a binary representation of the multiplier to the base rate. The multiplier can takeany value from 2 up to the maximum number of B-channels available on the interface.

30

B-IF2.02-02-TS

User information layer 1 protocol (octet 5)Bit
5 4 3 2 1
0 0 0 0 1

ITU-T standardized rate adaption V.110 and X.30. This implies the presence ofoctet 5a and optionally octets 5b, 5c and 5d as defined below.
Recommendation G.771 u-law
Recommendation G.711 A-law
Recommendation G.721 [11] 32 kbit/s ADPCM and Recommendation I.460.
Recommendations H.221 and H.242
Non-ITU-T standardized rate adaption. This implies the presence of octet 5aand, optionally, octets 5b, 5c and 5d. The use of this code point indicates thatthe user rate specified in octet 5a is defined by the user. Additionally, octets 5b,
5c and 5d, if present, are defined consistent with the user specified rate
adaption.
ITU-T standardized rate adaption V.120 [9]. This implies the presence of octets
5a and 5b as defined below, and optionally octets 5c and 5d.
ITU-T standardized rate adaption X.31 [14] HDLC flag stuffing.

0 0 0 1 0
0 0 0 1 1
0 0 1 0 0
0 0 1 0 1
0 0 1 1 10 1 0 0 0
0 1 0 0 1

All other values are reserved.
Note :

If the transfer mode is "circuit mode", and if the information transfer capability is"unrestricted digital information" or "restricted digital information"; and if the user
information layer 1 protocol is to be identified only to the addressed entity octet 5 shallbe omitted. Packet mode is for farther study. Otherwise, octet 5 shall be present.

Synchronous/Asynchronous (octet 5a)Bit
70
Synchronous data1
Asynchronous data
Note 1:

Octets 5b - 5d may be omitted in the case of synchronous user rates.

Negotiation (octet 5a)
Bit 0
In-band negotiation not possible
1
In-band negotiation not possible
Note 2: See Recommendations V.110 [7] and X.30 [8] or modem type recommendation

B-IF2.02-02-TS

31

Table 4-6/B-IF2.02(Q.931) (cont.)
Bearer capability information element
User rate (octet 5a)Bit
5 4 3 2 1
0 0 0 0 0
0 0 0 0 1
0 0 0 1 0
0 0 0 1 1
0 0 1 0 0
0 0 1 0 1
0 0 1 1 0
0 0 1 1 10 1 0 0 0
0 1 0 0 1
0 1 0 1 0
0 1 0 1 1
0 1 1 0 0
0 1 1 1 0
0 1 1 1 1
1 0 1 0 1
1 0 1 1 0
1 0 1 1 1
1 1 0 0 0
1 1 0 0 1
1 1 0 1 0
1 1 0 1 1
1 1 1 0 0
1 1 1 0 1
1 1 1 1 0
1 1 1 1 1

Rate is indicated by E-bits specified in Recommendation I.460 [15] or may benegotiated in-band
0.6 kbit/s Recommendations V.6 [16] and X.1 [17]1.2 kbit/s Recommendation V.6
2.4 kbit/s Recommendations V.6 and X.1
3.6 kbit/s Recommendation V.6
4.8 kbit/s Recommendations V.6 and X.1
7.2 kbit/s Recommendation V.6
8 kbit/s Recommendation I.460
9.6 kbit/s Recommendations V.6 and X.1
14.4 kbit/s Recommendation V.6
16 kbit/s Recommendation I.460
19.2 kbit/s Recommendation V.6
32 kbit/s Recommendation I.460
48 kbit/s Recommendations V.6 and X.1
56 kbit/s Recommendation V.6
0.1345 kbit/s Recommendation X.1
0.100 kbit/s Recommendation X.1
0.075/1.2 kbit/s Recommendations V.6 and X.1 (Note 3)
1.2/0.075 kbit/s Recommendations V.6 and X.1 (Note 3)
0.050 kbit/s Recommendations V.6 and X.1
0.075 kbit/s Recommendations V.6 and X.1
0.110 kbit/s Recommendations V.6 and X.1
0.150 kbit/s Recommendations V.6 and X.1
0.200 kbit/s Recommendations V.6 and X.1
0.300 kbit/s Recommendations V.6 and X.1
12 kbit/s Recommendation V.6

All other values are reserved.
Note 3:

The first rate is the transmit rate in the forward direction of the call. The second rate is
the transmit rate in the backward direction of the call.

Octet 5b for V.110 and X.30 rate adaption
Intermediate rate (octet 5b)
Bit
7 6
0 0 Not used
0 1 8 kbit/s
1 0 16 kbit/s
1 1 32 kbit/s

32

B-IF2.02-02-TS

Table 4-6/B-IF2.02(Q.931) (cont.)
Bearer capability information element
Network independent clock (NIC) on transmission (Tx) (octet 5b) (Note 1)
Bit
50
Not required to send data with network independent clock
1
Required to send data with network independent clock
Note 1:
Note 2:

Refers to transmission in the forward direction of the call.
See Recommendations V.110 [7] and X.30.

Network independent clock (NIC) on reception (Rx) (octet 5b) (Note 3)
Bit
40

Cannot accept data with network independent clock (i.e. sender does not support thisoptional procedure)
Can accept data with network independent clock (i.e. sender does support thisoptional procedure)

1
Note 3:Note 4:

Refers to transmission in the backward direction of the call.
See Recommendations V.110 [7] and X.30 [8].

Flow control on transmission (Tx) (octet 5b) (Note 5)Bit
30 Not required to send data with flow control mechanism
1 Required to send data with flow control mechanism
Note 5:Note 6:

Refers to transmission in the forward direction of the call.
See Recommendations V.110 and X.30.

Flow control on reception (Rx) (octet 5b) (Note 7)
Bit
20

Cannot accept data with flow control mechanism (i.e. sender does not support thisoptional procedure)
Can accept data with flow control mechanism (i.e. sender does support this optional
procedure)

1
Note 7:Note 8:Refers to transmission in the backward direction of the call
See Recommendations V.110 and X.30.

Octet 5b for V.120 [9] rate adaption
Rate adaption header/no header (octet 5b)Bit
7
0 Rate adaption header not included
1 Rate adaption header included
Multiple frame establishment support in data link (octet 5b)
Bit
6
0
1

Multiple frame establishment not supported. Only UI frames allowed
Multiple frame establishment supported

B-IF2.02-02-TS

33

Table 4-6/B-IF2.02(Q.931) (concl.)
Bearer capability information element
Mode of operation (octet 5b)
Bit
5
0
1

Bit transparent mode of operation
Protocol sensitive mode of operation

Logical link identifier negotiation (octet 5b)
Bit
4
0
1

Default, LLI = 256 only
Full protocol negotiation (Note)

Note :A connection over which protocol negotiation will be executed is indicated in bit 2 ofoctet 5b.

Assignor/assignee (octet 5b)
Bit
3
0
1

Message originator is "Default assignee"
Message originator is "Assignor only"

In-band/out-band negotiation (octet 5b)
Bit
2
0
1

Negotiation is done with USER INFORMATION messages on a temporary signalling
connection
Negotiation is done in-band using logical link zero

Note :

USER INFORMATION messages is not the object of this standard.

Number of stop bits (octet 5c)
Bit
7 6
0 0
0 1
1 0
1 1

Not used
1 bit
1.5 bits
2 bitsNumber of data bits excluding parity Bit if present (octet 5c)
Bit
5 4
0 0
0 1
1 0
1 1

Not used
5 bits7 bits8 bitsParity information (Octet 5c)
Bit
3 2 1
0 0 0
Odd
0 1 0
Even
0 1 1
None
1 0 0
Forced to 0
1 0 1
Forced to 1
All other values are reserved.

34

B-IF2.02-02-TS

Table 4-6/B-IF2.02(Q.931) (concl.)
Bearer capability information element
Mode duplex (octet 5d)
Bit
7
0
1

Half duplex
Full duplex

Modem type (octet 5d)Bit
6 5 4 3 2 1
0 0 0 0 0 0
through0 0 0 1 0 1
0 1 0 0 0 1
0 1 0 0 1 0
0 1 0 0 1 1
0 1 0 1 0 0
0 1 0 1 0 1
0 1 0 1 1 0
0 1 0 1 1 1
0 1 1 0 0 0
0 1 1 0 0 1
0 1 1 0 1 0
0 1 1 0 1 1
0 1 1 1 0 1
1 0 0 0 0 0
through
1 0 1 1 1 1
1 1 0 0 0 0
through
1 1 1 1 1 1national use
Recommendation V.21 [55]
Recommendation V.22 [56]
Recommendation V.22 bis [57]Recommendation V.23 [58]
Recommendation V.26 [59]Recommendation V.26 bis [60]
Recommendation V.26 ter [61]RecommendationV.27 [62]Recommendation V.27 bis [63]
Recommendation V.27 ter [64]Recommendation V.29 [65]Recommendation V.32 [66]national use

user specified

All other values reserved.

B-IF2.02-02-TS

35

Table 4-7/B-IF2.02(Q.931)
Bearer capability attributes
BC Attributes
Transfer mode Informationtransfer
capability
Circuit
SpeechStructure

Additional Attributes
Configuration Establishment

8 kHz integrity Point-to-point

Demand8 kHz integrity Point-to-point

DemandCircuitUnrestricted
data
Restricted data

8 kHz integrity Point-to-point

DemandCircuit

3,1 kHz audio

8 kHz integrity Point-to-point

DemandCircuitUnrestricted
8 kHz integrity Point-to-point
data withtones/announcements
Video
8 kHz integrity Point-to-point

DemandCircuitCircuit

Symmetry

Bi-directional
symmetric
Bi-directional
symmetric
Bi-directional
symmetric
Bi-directional
symmetric
Bi-directional
symmetric

DemandBi-directional
symmetric
Note :1 When the information transfer rate 2 u 64 kbit/s is used, 8 kHz integrity with Restricted
Differential Time Delay (RDTD) is offered.
Note :2 When multirate (64 kbit/s base rate) is indicated as the information transfer rate, Time Slot
Sequence integrity shall be provided.

4.5.6 Call identity*
4.5.7 Call state
The purpose of the Call state information element is to describe the current status of a call, (see 2.1) ora global interface state (see 2.4).
The Call state information element is coded as shown in Figure 4-13 and Table 4-8.
The length of this information element is three octets.

8

7

6

0

0

0

Codingstandard

Bit
5
4
3
2
Call state
10
10Information element identifier
Length of call state contents
Call state value / global interface state value(state value is coded in binary)Figure 4-13/B-IF2.02(Q.931)
Call state information element36

B-IF2.02-02-TS

1

Octets0123

Table 4-8/B-IF2.02(Q.931)
Call state information element
Coding standard (octet 3)
Bit
8 7
0 0
0 1
1 0
1 1
Note :ITU-Tstandardized coding, as described below
ISO/IEC standard (Note)
National standard (Note)
Standard defined for the network (either public or private) present on the networkside of the interface (Note)
These other coding standards should only be used only when the desired call statescannot be represented by ITU-T-standardized coding.

Call state value (octet 3)Bit
6 5 4 3 2 1
0 0 0 0 0 0
0 0 0 0 0 1
0 0 0 0 1 1
0 0 0 1 0 0
0 0 0 1 1 0
0 0 0 1 1 1
0 0 1 0 0 0
0 0 1 0 0 1
0 0 1 0 1 0
0 0 1 0 1 1
0 0 1 1 0 0
0 1 0 0 1 1
0 1 0 1 1 0

Public cell station State StateC 0 - Null
C 1 - Call initiatedC 3 - Outgoing call proceeding
C 4 - Call delivered
C 6 - Call present
C 7 - Call received
C 8 - Connect request
C 9 - Incoming call proceeding
C10 - Active
C11 - Disconnect request
C12 - Disconnect indication
C19 - Release request------ISDN state
N0- NullN1- Call initiatedN3- Outgoing call proceeding
N4- Call delivered
N6- Call present
N7- Call received
N8- Connect request
N9- Incoming call proceeding
N10 - Active
N11 - Disconnect request
N12 - Disconnect indication
N19 - Release request
N22 - Call abort

Global interface state value (octet 3)Bit
6 5 4 3 2 1
0 0 0 0 0 0
1 1 1 1 0 1
1 1 1 1 1 0

State
REST0 - Null
REST1 - Restart request
REST2 - Restart

All other values are reserved.

B-IF2.02-02-TS

37

4.5.8 Called party number
The purpose of the Called party number information element is to identify the called party of a call.
The Called party number information element is coded as shown in Figure 4-14 and Table 4-9.
The maximum length of this information element is digital network dependent.

8

7

0

1

1
Ext.
0

Bit
6
5
4
3
2
Called party number1
10
00
Information element identifier
Length of called party number contents
Type of number
Numbering plan
identification
Number digits (IA5 characters) (Note)

1

Octets01Note : The number digits appear in multiple octet 4’s in the same order in which theywould be entered, that is, the number digit which would be entered first is locatedin the first octet 4.
Figure 4-14/B-IF2.02(Q.931)
Called party number information element38

B-IF2.02-02-TS

2
3
4
etc.

Table 4-9/B-IF2.02(Q.931)
Called party number information element
Type of number (octet 3) (Note 1)
Bit
7 6 5
0 0 1
0 1 0
0 1 1
1 1 1

International number (Note 2)
National number (Note 2)
Network specific number (Note 3)
Reserved for extension

All other values are reserved.
Note 1: For the definition of international, national and subscriber number, see Recommendation
I.330 [18].
Note 2: Prefix or escape digits shall not be included.
Note 3: The type of number "network specific number" is used to indicate administration/service
number specific to the serving network, e.g. used to access an operator.
Numbering plan identification (octet 3)
4 3 2 10 0 0 1
1 0 0 01 0 0 11 1 1 1

ISDN/telephony numbering plan (Recommendation E.164 [19])National standard numbering plan
Private numbering plan
Reserved for extension

All other values are reserved.
Number digits (octets 4, etc.)
This field is coded with IA5 characters, according to the formats specified in the appropriate
numbering/dialling plan.

B-IF2.02-02-TS

39

4.5.9 Called party subaddress
The purpose of the Called party subaddress information element is to identify the subaddress of thecalled party of the call.
The Called party subaddress information element is coded as shown in Figure 4-15 and Table 4-10.
For the definition of subaddress see ITU-T Recommendation I.330 [18].
The maximum length of this information element is 23 octets.

8

Bit
5
4
3
Called party subaddress
1
1
1
0
0
Information element identifier
Length of called party subaddress contents
Type of subaddress
Odd/even0
indicator
Subaddress information
7

0

1 ext.

6

B-IF2.02-02-TS

1

Octets

0

1

1

0

2
3

0
Spare

Figure 4-15/B-IF2.02(Q.931)
Called party subaddress information element

40

2

4

Table 4-10/B-IF2.02(Q.931)
Called party subaddress information element

Type of subaddress (octet 3)
Bit
7 6 5
0 0 0
0 1 0

NSAP (X.213 [23]/ISO 8348 AD2 [24])User specified subaddress

All other values are reserved.
Odd/even indicator (octet 3)
401

Even number of address signals
Odd number of address signals

Note 1:The odd/even indicator is used when the type of subaddress is "user specified" and thecoding is BCD.

Subaddress information (octets 4, etc.)
The NSAP X.213/ISO8348AD2 address, shall be formatted as specified by octet 4 which contains
the Authority and Format Identifier (AFI). The encoding is made according to the "preferredbinary encoding" as defined in ITU-T Rec. X.213/ISO 8348 AD2 except when used for Terminal
selection at the S interface (see Note 3). For the definition of this type of subaddress, see
Recommendation I.334 [25].
For user specified subaddress, this field is encoded according to the user specification, subject to a
maximum length of 20 octets. When interworking with X.25 [5] networks BCD coding should beapplied.

B-IF2.02-02-TS

41

4.5.10 Calling party number
The purpose of the Calling party number information element is to identify the origin of a call.
The Calling party number information element is coded as shown in Figure 4-16, and Table 4-11.
The maximum length of this information element is digital network dependent.

80

0/1 ext.
1 ext.
0

Bit
7
6
5
4
3
2
1
Calling party number
1
1
0
1
1
0
0
Information element identifier
Length of calling party number contents
Type of number
Numbering plan identification
Presentation000Screening
Indicataor
Spareindicator
Number digits (IA5 characters)
Figure 4-16/B-IF2.02(Q.931)
Calling party number information element42

B-IF2.02-02-TS

Octets
1
2
3
3a*
4*

Table 4-11/B-IF2.02(Q.931)
Calling party number information element
Type of number (octet 3) (Note 1)
Bit
7 6 5
0 0 1
0 1 0
0 1 1
1 1 1

International number (Note 2)
National number (Note 2)
Network specific number (Note 3)
Reserved for extension

All other values are reserved.
Note 1: For the definition of international, national and subscriber number, (see Recommendation
I.330 [18]).
Note 2: Prefix or escape digits shall not be included.
Note 3: The type of number "network specific number" is used to indicate administration/service
number specific to the serving network, e.g. used to access an operator.
Numbering plan identification (octet 3)
Numbering plan (applies for type of number = 000, 001, 010 and 100)
Bit
4 3 2 10 0 0 1
1 0 0 01 0 0 11 1 1 1

ISDN/telephony numbering plan (Recommendation E.164 [19])National standard numbering plan
Private numbering plan
Reserved for extension

All other values are reserved.

B-IF2.02-02-TS

43

Table 4-11/B-IF2.02(Q.931) (concluded)
Calling party number information element
Presentation indicator (octet 3a)Bit
7 6 Meaning
0 0 Presentation allowed
0 1 Presentation restricted
1 0 Number not available due to interworking
1 1 Reserved
Note 1:
The meaning and the use of this field is defined in 3/Q.951 and 4/Q.951.
Screening indicator (octet 3a)
Bit
2 1 Meaning
0 0 User-provided, not screened
0 1 User-provided, verified and passed
1 0 User-provided, verified and failed
1 1 Network provided
Number digits (octets 4, etc.)
This field is coded with IA5 characters, according to the formats specified in the appropriate
numbering/dialling plan.

4.5.11 Calling party subaddress
The purpose of the Calling party subaddress information element is to identify a subaddress associatedwith the origin of a call.
The Calling party subaddress information element is coded as shown in Figure 4-17 and Table 4-12.
For the definition of subaddress, see Recommendation I.330 [21].
The maximum length of this information element is 23 octets.

44

B-IF2.02-02-TS80

1 ext.

Bit
5
4
3
Calling party subaddress
1
1
0
1
1
Information element identifier
Length of calling party subaddress contents
Type of subaddress
Odd/even0
indicator
Subaddress information
7

6

2

1

Octets

0

1

1

0

2
3

0
Spare

4

Figure 4-17/B-IF2.02(Q.931)
Calling party subaddress information element

Table 4-12/B-IF2.02(Q.931)
Calling party subaddress information element
Type of subaddress (octet 3)
Bit
7 6 5
0 0 0
0 1 0

NSAP(ITU-T Rec. X.213 [23]/ISO 8348 AD2 [24])User specified subaddress

All other values are reserved.
Odd/even indicator (octet 3)
Bit
4
0
1
Note 1:

Even number of address signals
Odd number of address signals
The odd/even indicator is used when the type of subaddress is "user specified" andthe coding is BCD.

Subaddress information (octets 4, etc.)
The NSAP ITU-T Rec. X.213/ISO 8348 AD2 address, shall be formatted as specified by octet 4
which contains the Authority and Format Identifier (AFI). The encoding is made according to the"preferred binary encoding" as defined in CCITT Rec. X.213/ISO 8348 AD2 except when used for
Terminal selection at the S interface. For the definition of this type of subaddress, see
Recommendation I.334 [25].
For user specified subaddress, this field is encoded according to the user specification, subject to a
maximum length of 20 octets. When interworking with X.25 [5] networks BCD coding should beapplied.

B-IF2.02-02-TS

45

4.5.12 Cause
The content and use of the Cause information element is defined in Recommendation Q.850 [67].
4.5.13 Channel identification
The purpose of the Channel identification information element is to identify a channel within theinterface(s) controlled by these signalling procedures.
The Channel identification information element is coded as shown in Figures 4-18 and 4-19 and Table
4-13. The channel identification element may be repeated in a message, e.g. to list several acceptablechannels during channel negotiation.
The channel identification element may be repeated in a message, e.g. to list several acceptablechannels during channel negotiation.The default maximum length for this information element is
network dependent.

8

7

0

0

1 ext.

Int. id.
present

0/1
ext.
1 ext.

Bit•
5
4
3
Channel identification01
1
0
Information element identifier
Length of channel identification contents
Int. type0
Pref./Excl. D-channel
spare
ind.
Interface identifier
6

Coding standard

Number/Map2

1

Octets001Info. channel
selection

Channel type/Map element type

Channel number/Slot map (Note 3)

Note 1: When the "interface identifier present" field in octet 3 indicates "interface
implicitly identified" octet 3.1 is omitted. When octet 3.1 is present it may be
extended by using the extension bit (bit 8).
Note 2: When the "interface type" field in octet 3 indicates "basic interface", octets 3.2 and3.3 are functionally replaced by the "information channel selection" field in octet
3, and thus omitted.
Note 3: When channel number is used and a single channel is indicated bit 8 shall be set to"1". When channel number is used and multiple channels are indicated, bit 8 shallbe used as an extension bit to indicate an extension to subsequent channels andcoded according to the rules specified in 4.5.1.
Note 4: When channel number is used, this octet may be repeated to indicate multiple
channels.
Note 5: These octets shall be omitted when the entire interface is to be identified.
Figure 4-18/B-IF2.02(Q.931)
Channel identification information element46

B-IF2.02-02-TS

2
3
3.1*,
etc.
(Note 1)
3.2*
(Note 2)
(Note 5)
3.3*
(Note 2)
(Note 4)(Note 5)

Table 4-13/ B-IF2.02(Q.931)
Channel identification information element
Interface identifier present (octet 3)Bit
70 Interface implicitly identified (Note 1)
1 Interface explicitly identified in one or more octets, beginning with octet 3.1.
Note 1:

The interface which includes the D-channel carrying this information element isindicated.

Interface type (octet 3)Bit
60 Basic interface
1 Other interface e.g. primary rate (Note 2)
Note 2:The type of interface should be understood because the interface is identified by the"interface identifier present" field (octet 3, bit 7) and the interface identifier field (octet3.1), if any.

Preferred/Exclusive (octet 3)Bit
40 Indicated channel is preferred
1 Exclusive; only the indicated channel is acceptable
Note 3:Preferred/exclusive has significance only for B-channel selection.

D-channel indicator (octet 3)
Bit
30 The channel identified is not the D-channel
1 The channel identified is the D-channel
Note 4:D-channel indication has significance in D-channel use. No other information affects Dchannel use.

Information channel selection (octet 3) (Note 5)
Basic interface
Other interfaces
Bit
2 1
0 0 No channel
No channel
0 1 B1 channel
As indicated in following octets
1 0 B2 channel
Reserved
1 1 Any channel (Note 6) Any channel
Note 5: The information channel selection does not apply to the D-channel.
Note 6: This value shall be used on a basic access when both B-channels are to be identified, e.g.
multirate (64 kbit/s base rate). This shall not be used for restart procedures.

B-IF2.02-02-TS

47

Table 4-13/ B-IF2.02(Q.931)(concluded)
Channel identification information element
Interface identifier (octet 3.1)
Binary code assigned to the interface at subscription time. At subscription time, the binary code forthe interface will specify the number of octets to be used and the content of each octet.
Coding standard (octet 3.2)
Bit
7 6
0 0
0 1
1 0
1 1

CCITT standardized coding, as described below
ISO/IEC standard (Note 1)
National standard (Note 1)
Standard defined for the network (either public or private) present on the network sideof the interface (Note 1)

Note 1: These other coding standards should only be used when the desired call states cannot be
represented by CCITT-standardized coding.
Number/map (octet 3.2)
Bit
5
0
1

Channel is indicated by the number in the following octet.
Channel is indicated by the slot map (Map) in the following octet(s).

Note 2: When the information transfer rate is 64 kbit/s the channel number shall be used unlessthere exists a bilateral agreement between the user and the network to use the slot map.
Note 3: Slot map shall be used when supporting the multirate (64 kbit/s base rate) bearercapability on a primary rate access.
Channel type/map element type (octet 3.2)
Bit
4 3 2 10 0 1 10 1 1 01 0 0 01 0 0 1B-channel units(Note 4)
H0-channel units
H11-channel units
H12-channel units

All other values are reserved.
Note 4: This value shall be used for multirate (64 kbit/s base rate) bearer capability.
Channel number (octet 3.3)
Binary number assigned to the channel. For B-channels, the channel number equals the time slot
number. See Recommendation I.431 [27].
Note 1: Either "Channel Number" or "Slot map" is used exclusively, depending on the"Number/Map" information.
Slot map (octet 3.3)
Bit position(s) in slot map corresponding to time slot(s) used by the channel is set to 1, see Figure
4-19. The remaining bits are set to 0.
Note 2: The length of the slot-map (in bits) is defined by the capacity of the interface type (e.g.
1534 kbit/s or 2048 kbit/s for a primary rate interface) divided by the capacity of thechannel type/map-element type (e.g. 64 kbit/s for a B-channel). The length of the slot
map is the smallest number of complete octets that contain the length in bits.

48

B-IF2.02-02-TS

8
24
16
8

7
23
15
7

6
22
14
6

Bit
5
4
21
20
13
12
5
4
1544 kbit/s

3
19
11
3

2
18
10
2

1
17
9
1

Octets
3.3.1
3.3.2
3.3.3

8
31
23
15
7

7
30
22
14
6

6
29
21
13
5

Bit
5
4
28
27
20
19
12
11
4
3
2048 kbit/s

3
26
18
10
2

2
25
17
9
1

1
24
16
8
0

Octets
3.3.1
3.3.2
3.3.3
3.3.4

a) Primary rate interface, map element type = B channel
Bit
8

7

6

8

7

6

5

4
d(4)
1544 kbit/s

Bit
5
4
e(5)
d(4)
2048 kbit/s

3
c(3)

2
b(2)

1
a(1)

Octets
3.3

3
c(3)

2
b(2)

1
a(1)

Octets3.3b) Primary rate interface, map element type = H0 channel
Note 1:
Note 2:

See Recommendation I.431 [27], Annex A, concerning meaning of a-e.
Number within ( ) indicates the associated H0-channel number used whencorresponding H0-channel is represented by channel number in octet 3.3.

8

7

Bit
6

5

4

3

2

1
H11(1)

Octets3.3

32

1
H12(1)

Octets3.3

1544 kbit/s
Bit
8

7

6

5

4

2048 kbit/sc) Primary rate interface, map element type = H1-channel
Note 3:Note 4:

Number within ( ) indicates the associated H1-channel number used whencorresponding H1-channel is represented by channel number in octet 3.3.
For 2048 kbit/s interface, H11 slot will be indicated by the same format.
Figure 4-19/ B-IF2.02(Q.931)
Slot map field

B-IF2.02-02-TS

49

4.5.14 Corgestion level*
4.5.15 Date/time*
4.5.16 Display*
4.5.17 High layer compatibility
The purpose of the High layer compatibility information element is to provide a means which should
be used by the remote user for compatibility checking. See Annex B.
The High layer compatibility information element is coded as shown in Figure 4-23 and Table 4-15.
The High layer compatibility information element can be repeated in the SETUP message to indicate
dual high layer capabilities for selection. By default, if the High layer compatibility information
element is repeated without the Repeat indicator information element, it shall be interpreted asincreasing order of priority.
The maximum length of this information element is five octets.
Note :The High layer compatibility information element is transported transparently by an ISDN
between a call originating entity, e.g. a calling user and the addressed entity, e.g. a remoteuser or a high layer function network node addressed by the call originating entity.
However, if explicitly requested by the user (at subscription time), a network which
provides some capabilities to realize teleservices may interpret this information to provide
a particular service.

Bit•
7
6
5
4
3
High layer compatibility
1
1
1
1
1
Information element identifier
Length of high layer compatibility contents
Coding standard
Interpretation

8
0

1 ext.
0/1 ext.
1 ext.

2

1

Octets0

1

1Presentation methodof protocol profile
High layer characteristics identification
Extended high layer characteristics identification

Note : This octet may be present when octet 4 indicates Maintenance or Management.
Figure 4-23/B-IF2.02(Q.931)
High layer compatibility information element50

B-IF2.02-02-TS

2
3
4
4a*
(Note)

Table 4-15/B-IF2.02(Q.931)
High layer compatibility information element
Coding standard (octet 3)
Bit
7 6
0 0
CCITT standardized coding, as described below
0 1
ISO/IEC standard (Note 1)
1 0
National standard (Note 1)
1 1Standard defined for the network (either public or private) present on the network side of theinterface (Note 1)
Note 1:

These other coding standards should only be used only when the desired high layer compatibility
cannot be represented by CCITT standardized coding.
Interpretation (octet 3)
Bit
5 4 3
1 0 0
First (primary or only) high layer characteristics identification (in octet 4) to be used in the call
All other values are reserved.
Note 2:"Interpretation" indicates how the "High layer characteristics identification" (in octet 4) should beinterpreted.

Note 3:Currently, "Interpretation" has only a single value. However, "Interpretation", when enhanced, will
be able to indicate how the "High layer characteristics identification" in the same information
element shall be interpreted when multiple "High layer characteristics identifications" are used andexact relationship among them needs to be indicated (e.g. sequential usage, alternative list,
simultaneous usage). Such enhancements in conjunction with the possible negotiation procedures
are left for further study.
Presentation method of protocol profile (octet 3)
Bit
2 1
0 1
High layer protocol profile (without specification of attributes)
All other values are reserved.
Note 4:Currently, "Presentation method of protocol profile" has only a single value, i.e. a "profile value" isused to indicate a service to be supported by high layer protocols as required. Necessity of otherpresentation methods, e.g. service indications in the forum of layer-by-layer indication of protocols
to be used in high layers, is left for further study.
High layer characteristics identification (octet 4)
Bit76543210000001
Telephony
0000100
Facsimile Group 2/3 (Recommendation F.182 [68])0100001
Facsimile Group 4 Class I (Recommendation F.184 [69])0100100
Teletex service, basic and mixed mode of operation (Recommendation F.230 [70]) andfacsimile service Group 4, Classes II and III (Recommendation F.184)
0101000
Teletex service, basic and processable mode of operation (Recommendation F.220 [71])0110001
Teletex service, basic mode of operation (Recommendation F.200 [72])0110010
Syntax based Videotex (Recommendations F.300 [73] and T.102 [74])0110011
International Videotex interworking via gateways or interworking units (Recommendations
F.300 and T.101 [75])0110101
Telex service (Recommendation F.60 [76])0111000
Message Handling Systems (MHS) (X.400 - Series Recommendations [77])1000001
OSI application (Note 2) (X.200 - Series Recommendations [78])1011110
Reserved for maintenance (Note 4)
1011111
Reserved for management (Note 4)
1100000
Audio visual (Recommendation F.721 [79])1100001
through
Reserved for audiovisual services (F.700 - Recommandations Series [80])11011111111111
Reserved

B-IF2.02-02-TS

51

Table 4-15/B-IF2.02(Q.931) (continued)
High layer compatibility information element
All other values are reserved.
Note 1:
Note 2:
Note 3:Note 4:The coding above applies in case of "Coding standard" = "CCITT standard" and"Presentation method of protocol profile" = "High layer protocol profile".
Further compatibility checking will be executed by the OSI high layer protocol.
Code points are added only to those services for which CCITT Recommendations areavailable. See also Recommendation I.241 [34].
When this coding is included, octet 4 may be followed by octet 4a.

Extended high layer characteristics identification (octet 4a)
Bit
76543210000001
0000100
0100001
0100100
0101000
0110001011001001100110110101
0111000
1000001
101111010111111100000
1100001
through
11011111111111

TelephonyFacsimile Group 2/3 (Recommendation F.182)
Facsimile Group 4 Class I (Recommendation F.184)
Teletex service, basic and mixed mode of operation (Recommendation F.230) andfacsimile service Group 4, Classes II and III (Recommendation F.184)
Teletex service, basic and processable mode of operation (Recommendation
F.220)
Teletex service, basic mode of operation (Recommendation F.200)
Syntax based Videotex (Recommendations F.300 and T.102)
International Videotex interworking via gateways or interworking units(Recommendations F.300 and T.101)
Telex service (Recommendation F.60)
Message Handling Systems (MHS) (X.400 - Series Recommendations)
OSI application (Note 2) (X.200 - Series Recommendations)Not available for assignment
Not available for assignment
Audio visual (Recommendation F.721)
Reserved for audiovisual services (F.700 - Series Recommendations)
Reserved

All other values are reserved.
Note :

52

It should that high layer regurlated by every country might be used besides these case.

B-IF2.02-02-TS

4.5.18 Keypad facility*
4.5.19 Low layer compatibility
The purpose of the Low layer compatibility information element is to provide a means which should
be used for capability checking by an addressed entity (e.g. a remote user or an interworking unit or ahigh layer function network node addressed by the calling user). The Low layer compatibility
information element is transferred transparently by an ISDN between the call originating entity (e.g.
the calling user) and the addressed entity. See Annex B and Annex I.
If low layer compatibility negotiation is allowed by the network (see Annex J), the Low layercompatibility information element is also passed transparently from the addressed entity to originating
entity.
The Low layer compatibility information element is coded as shown in Figure 4-25 and Table 4-16.
The maximum length of this information element is 18 octets.

B-IF2.02-02-TS

53

Bit
8

7

0

0/1 ext.
1 ext.
1 ext.
1 ext.
0/1 ext.
0/1 ext.
0/1 ext.
0/1 ext.
0/1 ext.
1 ext.
0/1 ext.
0/1 ext

65432
Low layer compatibility
1
1
1
1
1
0
Information element identifier
Length of the low layer compatibility contents
Coding standard
Information transfer capability
Negot.
000
00
indic.
Spare
Transfer mode
Information transfer rate
Rate multiplier01
Layer 1 ident.
Synch./
Negot.
asynch.
Intermediate rate
Hdr/no Multifra
Hdrme
Number of stop bits
Duplexmode
10
layer 2 ident.
Mode

1 ext.

Octets

0

1

0

2
3
3a*
4
4.1*
(Note 1)
5*

User information layer 1 protocol
User rate
NIC onTx
Mode

NIC onFlow
Flow
Rx
control
control
Negot. Assignor/ In-band
LLI
Assignoree negot
Number of data bits
Parity

0
Spare
0
Spare

Modem type
User information layer 2 protocol
00Q.933 use
Spare
User specified layer 2 protocol information
Window size (k)0/1 ext
0/1 ext.

11
layer 3 ident.
Mode

1 ext.
0/1 ext.

0

1 ext.

0
Spare

User information layer 3 protocol
0

0
Spare
Optional layer 3 protocol information
0

0

0Default packet size
Packet window size

Figure 4-25/B-IF2.02(Q.931)
Low layer compatibility information element

B-IF2.02-02-TS

5a*(Note 2)5b*(Note 3)5b*(Note 4)5c*(Note 2)5d*(Note 2)6*6a*(Note 5)6a*(Note 6)6b*(Note 5)7*

0

1 ext.

54

1

0

7a*
(Note 7)7a*(Note 8)7b*(Note 7)7c*(Note 7)

Note 1: This octet is required if octet 4 indicates multirate (64 kbit/s base rate). Otherwise, it shallnot be present.
Note 2: This octet may be present if octet 3 indicates unrestricted digital information and octet 5
indicates either of the CCITT standardized rate adaptions V.110 and X.30 or V.120 [9]. It
may also be present if octet 3 indicates 3.1 kHz audio and octet 5 indicates G.711.
Note 3: This octet is significant only if octet 5 indicates CCITT standardized rate adaption (V.110 [7]and X.30 [8]).
Note 4: This octet is significant only if octet 5 indicates CCITT standardized rate adaption V.120 [9].
Note 5: This octet may be present only if octet 6 indicates certain acknowledged mode HDLC
elements of procedure as indicated in Table 4-16.
Note 6: This octet may be present only if octet 6 indicates user specified layer 2 protocol.
Note 7: This octet may be present only if octet 7 indicates a layer 3 protocol based on CCITT X.25 |ISO/IEC 8208 or CCITT Rec. X.223 | ISO 8878 as indicated in Table 4-16.
Note 8: This octet may be present only if octet 7 indicates user specified layer 3 protocol.

B-IF2.02-02-TS

55

Table 4-16/B-IF2.02(Q.931)
Low layer compatibility information element
Coding standard (octet 3)
bits
7 6
0 0
0 1
1 0
1 1

CCITT standardized coding, as described below
ISO/IEC standard (Note 1)
National standard (Note 1)
Standard defined for the network (either public or private) present on the network side of theinterface (Note 1)

Note 1:

These other coding standards should only be used only when the desired low layer compatibility
cannot be represented by CCITT-standardized coding.

Information transfer capability (octet 3)
Bit
5 4 3 2 1
0 0 0 0 0
0 1 0 0 0
0 1 0 0 1
1 0 0 0 0
1 0 0 0 1
1 1 0 0 0

SpeechUnrestricted digital information
Restricted digital information
3.1 kHz audio
Unrestricted digital information with tones/announcements
Video

All other values are reserved.
Negotiation indicator (octet 3a)
Bit
7
0
1

Out-band negotiation not possible
Out-band negotiation possible

Note 2:

When octet 3a is omitted, "out-band negotiation not possible" shall be assumed.

Transfer mode (octet 4)
Bit
7 6
0 0
1 0

Circuit mode
Packet-mode

All other values are reserved.
Information transfer rate (octet 4)Bit
5 4 3 2 1
0 0 0 0 0
1 0 0 0 0
1 0 0 0 1
1 0 0 1 1
1 0 1 0 1
1 0 1 1 1
1 1 0 0 0

Circuit mode
Packet-mode
This code shall be used for all packet calls
64 kbit/s
2 u 64 kbit/s
384 kbit/s
1536 kbit/s
1920 kbit/s
Multirate (64 kbit/s base rate)

All other values are reserved.
Note 1:
Note 2:

When the information transfer rate 2 u 64 kbit/s is used the coding of octets 3 and 4 refer to both
64 kbit/s channels.
Additional attributes are defined in Table 4-17.

Rate multiplier (octet 4.1)
Coded as a binary representation of the multiplier to the base rate. The multiplier can take any value from 2
up to the maximum number of B-channels available on the interface.

56

B-IF2.02-02-TS

Table 4-16/B-IF2.02(Q.931) (continued)
Low layer compatibility information element
User information layer 1 protocol (octet 5)Bit
5 4 3 2 1
0 0 0 0 1
CCITT standardized rate adaption V.110 [7] and X.30 [8]. This implies the presenceof octet 5a and optionally octets 5b, 5c and 5d as defined below.
0 0 0 1 0
Recommendation G.711 [10] m-law.
0 0 0 1 1
Recommendation G.711 A-law.
0 0 1 0 0
Recommendation G.721 [11] 32 kbit/s ADPCM and Recommendation I.460 [15].
0 0 1 0 1
Recommendations H.221 and H.242.
0 0 1 1 1
Non-CCITT standardized rate adaption. This implies the presence of octet 5a and,optionally, octets 5b, 5c and 5d. The use of this code point indicates that the user rate
specified in octet 5a is defined by the user. Additionally, octets 5b, 5c and 5d, if
present, are defined consistent with the user specified rate adaption.
0 1 0 0 0
CCITT standardized rate adaption V.120 [9]. This implies the presence of octets 5aand 5b as defined below, and optionally octets 5c and 5d.
0 1 0 0 1
CCITT standardized rate adaption X.31 [14] HDLC flag stuffing.
All other values are reserved.
Note 3:

If the transfer mode is "circuit mode" and if the information transfer capability is "unrestricteddigital information" or "Restricted digital information", and if a specific user information layer 1
protocol is to be identified to the addressed entity octet 5 shall be present. If the transfer mode ispacket mode, octet 5 may be omitted.

Synchronous/Asynchronous (octet 5a)Bit
70
Synchronous data1
Asynchronous data
Note 1:

Octets 5b-5d may be omitted in the case of synchronous user rates.

Negotiation (octet 5a)Bit
60In-band negotiation not possible
1
In-band negotiation possible
Note 2:

See Recommendations V.110 [7] and X.30 [8] or modem type recommendations.

User rate (octet 5a)Bit
5 4 3 2 1
0 0 0 0 0
0 0 0 0 1
0 0 0 1 0
0 0 0 1 1
0 0 1 0 0
0 0 1 0 1
0 0 1 1 0
0 0 1 1 10 1 0 0 0
0 1 0 0 1
0 1 0 1 0
0 1 0 1 1
0 1 1 0 0
0 1 1 1 0

Rate is indicated by E-bits specified in Recommendation I.460 or may be negotiatedin-band
0.6 kbit/s Recommendations V.6 [16] and X.1 [17]1.2 kbit/s Recommendation V.6
2.4 kbit/s Recommendations V.6 and X.1
3.6 kbit/s Recommendation V.6
4.8 kbit/s Recommendations V.6 and X.1
7.2 kbit/s Recommendation V.6
8 kbit/s Recommendation I.460
9.6 kbit/s Recommendations V.6 and X.1
14.4 kbit/s Recommendation V.6
16 kbit/s Recommendation I.460
19.2 kbit/s Recommendation V.6
32 kbit/s Recommendation I.460
48 kbit/s Recommendations V.6 and X.1

B-IF2.02-02-TS

57

Table 4-16/ B-IF2.02(Q.931) (continued)
Low layer compatibility information element
0 1 1 1 1
1 0 0 0 0
1 0 1 0 1
1 0 1 1 0
1 0 1 1 1
1 1 0 0 0
1 1 0 0 1
1 1 0 1 0
1 1 0 1 1
1 1 1 0 0
1 1 1 0 1
1 1 1 1 0
1 1 1 1 1

56 kbit/s Recommendation V.6
64 kbit/s Recommendation X.1
0.1345 kbit/s Recommendation X.1
0.100 kbit/s Recommendation X.1
0.075/1.2 kbit/s Recommendations V.6 and X.1 (Note 3)
1.2/0.075 kbit/s Recommendations V.6 and X.1 (Note 3)
0.050 kbit/s Recommendations V.6 and X.1
0.075 kbit/s Recommendations V.6 and X.1
0.110 kbit/s Recommendations V.6 and X.1
0.150 kbit/s Recommendations V.6 and X.1
0.200 kbit/s Recommendations V.6 and X.1
0.300 kbit/s Recommendations V.6 and X.1
12 kbit/s Recommendation V.6

All other values are reserved.
Note 3:

The first rate is the transmit rate in the forward direction of the call. The second rate is thetransmit rate in the backward direction of the call.

Octet 5b for V.110 [7] and X.30 [8] rate adaption
Intermediate rate (octet 5b)
Bit
7 6
0 0
0 1
1 0
1 1

Not used
8 kbit/s
16 kbit/s
32 kbit/s

Network independent clock (NIC) on transmission (Tx) (octet 5b) (Note 1)
Bit
5
0
1

Not required to send data with network independent clock
Required to send data with network independent clock

Note 1:
Note 2:

Refers to transmission in the forward direction of the call.
See Recommendations V.110 and X.30.

Network independent clock (NIC) on reception (Rx) (octet 5b) (Note 3)
Bit
40

Cannot accept data with Network Independent Clock (i.e. sender does not support this optional
procedure)
Can accept data with Network Independent Clock (i.e. sender does support this optional
procedure)

1
Note 3:Note 4:58

Refers to transmission in the backward direction of the call.
See Recommendations V.110 [7] and X.30 [8].

B-IF2.02-02-TS

Table 4-16/ B-IF2.02(Q.931) (continued)
Low layer compatibility information element
Flow control on transmission (Tx) (octet 5b) (Note 5)
Bit
30
Not required to send data with flow control mechanism
1
Required to send data with flow control mechanism
Note 5:Note 6:

Refers to transmission in the forward direction of the call.
See Recommendations V.110 and X.30.

Flow control on reception (Rx) (octet 5b) (Note 7)
Bit
20
Cannot accept data with flow control mechanism (i.e. sender does not support this optional procedure)1
Can accept data with flow control mechanism (i.e. sender does support this optional procedure)
Note 7:Note 8:Refers to transmission in the backward direction of the call.
See Recommendations V.110 and X.30.

Octet 5b for V.120 [9] Rate adaption
Rate adaption header/no header (octet 5b)
Bit
70Rate adaption header not included1
Rate adaption header included
Multiple frame establishment support in data link (octet 5b)
Bit
60Multiple frame establishment not supported. Only UI frames allowed
1
Multiple frame establishment supported
Mode of operation (octet 5b)
Bit
50
Bit transparent mode of operation
1
Protocol sensitive mode of operation
Logical link identifier negotiation (octet 5b)
Bit
40
Default, LLI = 256 only
1
Full protocol negotiation (Note)
Note :A connection over which protocol negotiation will be executed is indicated in bit 2 of octet 5b.

Assignor/assignee (octet 5b)
Bit
30
Message originator is "default assignee"
1
Message originator is "assignor only"

B-IF2.02-02-TS

59

Table 4-16/ B-IF2.02(Q.931) (continued)
Low layer compatibility information element
In-band/out-band negotiation (octet 5b)
Bit
2
0
1

Negotiation is done with USER INFORMATION messages on a temporary signalling connection
Negotiation is done in-band using logical link zero

Number of stop bits (octet 5c)
Bit
7 6
0 0
0 1
1 0
1 1

Not used
1 bit
1.5 bits
2 bitsNumber of data bits excluding parity bit if present (octet 5c)
Bit
5 4
0 0
0 1
1 0
1 1

Not used
5 bits7 bits8 bitsParity information (octet 5c)
Bit
3 2 1
0 0 0
0 1 0
0 1 1
1 0 0
1 0 1

Odd
Even
None
Forced to 0
Forced to 1

All other values are reserved.
Duplex mode (octet 5d)
Bit
7
0
1

60

Half duplex
Full duplex

B-IF2.02-02-TS

Table 4-16/ B-IF2.02(Q.931) (continued)
Low layer compatibility information element
Modem type (octet 5d)Bit
6 5 4 3 2 1
0 0 0 0 0 0
through0 0 0 1 0 1
0 1 0 0 0 1
0 1 0 0 1 0
0 1 0 0 1 1
0 1 0 1 0 0
0 1 0 1 0 1
0 1 0 1 1 0
0 1 0 1 1 1
0 1 1 0 0 0
0 1 1 0 0 1
0 1 1 0 1 0
0 1 1 0 1 1
0 1 1 1 0 0
1 0 0 0 0 0
through
1 0 1 1 1 1
1 1 0 0 0 0
through
1 1 1 1 1 1

National use
Recommendation V.21
Recommendation V.22
Recommendation V.22 bis
Recommendation V.23
Recommendation V.26
Recommendation V.26 bis
Recommendation V.26 ter
Recommendation V.27
Recommendation V.27 bis
Recommendation V.27 ter
Recommendation V.29
Recommendation V.32
National use
User specified

All other values reserved.
User information layer 2 protocol (octet 6)Bit
5 4 3 2 1
0 0 0 0 1
0 0 0 1 0
0 0 1 1 0
0 1 1 1 10 1 0 0 0
0 1 0 0 1
0 1 0 1 0
0 1 0 1 1
0 1 1 0 0
0 1 1 0 1
0 1 1 1 0
0 1 1 1 1
1 0 0 0 0
1 0 0 0 1

Basic mode ISO 1745 [36]Recommendation Q.921 (I.441) [3] (Note 4)
Recommendation X.25 [5], link layer (Notes 1, 4)
Recommendation X.25 Multilink (Note 4)
Extended LAPB; for half duplex operation (T.71 [37])
HDLC ARM (ISO 4335) [38] (Note 4)
HDLC NRM (ISO 4335) (Note 4)
HDLC ABM (ISO 4335) (Note 4)
LAN logical link control (ISO 8802/2) [39]Recommendation X.75 [40]. Single Link Procedure (SLP) (Note 4)
Recommendation Q.922 [ ] (Note 4)Core aspects of Recommendation Q.922
User specified (Note 2)
ISO 7776 DTE-DTE operation (Notes 3, 4)

All other values are reserved.
Note 1:
Note 2:
Note 3:Note 4:This Recommendation is compatible with ISO 7776 DTE-DCE operation.
When this coding is included, octet 6a will include user coding for the user specified Layer 2
protocol.
This Standard is compatible with Recommendation X.75 modified by the application rules
defined in Recommendation T.90.
When this coding is included, octets 6a and 6b with CCITT encoding may be included.

B-IF2.02-02-TS

61

Table 4-16/ B-IF2.02(Q.931) (continued)
Low layer compatibility information element
Octet 6a for CCITT codings
Mode of operation (octet 6a)
Bit
7 6
0 1
1 0

Normal mode of operation
Extended mode of operation

All other values are reserved.
Q.933 use (octet 6a)
Bit
2 1
0 0

For use when the coding defined in Recommendation Q.933 is not used

All other values are reserved.
Octet 6a for user protocol
User specified layer 2 protocol information (octet 6a)
The use and coding of octet 6a is according to user defined requirements.
Window size (k) (octet 6b)
Bit 7-1 binary coding of k parameter value in the range from 1 to 127.
User information layer 3 protocol (octet 7)
Bit
5 4 3 2 1
0 0 0 1 0
0 0 1 1 0
0 0 1 1 10 1 0 0 0
0 1 0 0 1
0 1 0 1 0
0 1 0 1 1
1 0 0 0 0

Recommendation Q.931 (I.451)
Recommendation X.25, packet layer (Note 2)
ISO/IEC 8208 [41] (X.25 packet level protocol for data terminal equipment) (Note 2)
CCITT Rec. X.223 | ISO 8878 [81] (use of ISO/IEC 8208 [41] and Recommendation
X.25 to provide the OSI-CONS) (Note 2)
ISO/IEC 8473 [43] (OSI connectionless mode protocol)
Recommendation T.70 [32] minimum network layer
ISO/IEC TR 9577 [82] (Protocol identification in the network layer)
User specified (Note 1)

All other values are reserved.
Note 1:
Note 2:

When this coding is included, octet 7a will included user coding for the user specified layer 3
protocol.
When this coding is included, octets 7a, 7b and 7c with CCITT encoding may be included.

Octet 7a for CCITT codings
Mode of operation (octet 7a)
Bit
7 6
0 1
1 0

Normal packet sequence numbering
Extended packet sequence numbering

All other values are reserved.

62

B-IF2.02-02-TS

Table 4-16/ B-IF2.02(Q.931) (continued)
Low layer compatibility information element
Octet 7a for user protocol
User specified layer 3 protocol information (octet 7a)
The use and coding of octet 7a depends on user defined requirements.
Default packet size (octet 7b)
Bit
4 3 2 10 1 0 00 1 0 10 1 1 00 1 1 1
1 0 0 01 0 0 11 0 1 01 0 1 11 1 0 0

Default packet size 16 octets
Default packet size 32 octets
Default packet size 64 octets
Default packet size 128 octets
Default packet size 256 octets
Default packet size 512 octets
Default packet size 1024 octets
Default packet size 2048 octets
Default packet size 4096 octets

All other values are reserved.
Packet window size (octet 7c)
Bits 7-1 binary coding of packet window size value in the range from 1 to 127.

B-IF2.02-02-TS

63

Table 4-17/ B-IF2.02(Q.931)
Low layer compatibility attributes

Transfermode
CircuitCircuitCircuitCircuitCircuitCircuit
PacketNote 1:
Note 2:

LLC attributes
Information transfer
capability
SpeechStructure
8 kHz integrity

Additional attributes
Configuration Establishment
Point-to-point

Symmetry

DemandBi-directional
symmetric
Unrestricted data
8 kHz integrity
Point-to-point
DemandBi-directional
symmetric
Restricted data
8 kHz integrity
Point-to-point
DemandBi-directional
symmetric
3.1 kHz audio
8 kHz integrity
Point-to-point
DemandBi-directional
symmetric
Unrestricted data with
8 kHz integrity
Point-to-point
DemandBi-directional
tones/announcements
symmetricVideo
8 kHz integrity
Point-to-point
DemandBi-directional
symmetric
Unrestricted data
Service data unit
Point-to-point
DemandBi-directional
integrity
symmetric
When the information transfer rate 2 u 64 kbit/s is used, 8 kHz integrity with Restricted
Differential Time Delay (RDTD) is offered.
When multirate (64 kbit/s base rate) is indicated as the information transfer rate, Time Slot
Sequence integrity shall be provided.

4.5.20 More data*
4.5.21 Network-specific facilities*
4.5.22 Notification indicator
The purpose of the Notification indicator information element is to indicate information pertaining toa call.
The Notification indicator information element is coded as shown in Figure 4-28 and Table 4-19.
The maximum length of this information element is three octets.
Bit
8

7

0

0

1 ext.

65
4
3
Notification indicator1001Information element identifier
Length of notification indicator contents
Notification description
Figure 4-28/B-IF2.02(Q.931)
Notification indicator information element64

B-IF2.02-02-TS

2

1

Octets

1

1

1
2
3

Table 4-19/B-IF2.02(Q.931)
Notification indicator information element

Notification description (octet 3)Bit
7 6 5 4 3 2 1
0 0 0 0 0 0 0
0 0 0 0 0 0 1

User suspended
User resumed

All other values are reserved.

4.5.23 Progress indicator
The purpose of the Progress indicator information element is to describe an event which has occurred
during the life of a call. The information element may occur two times in a message.
The Progress indicator information element is coded as shown in Figure 4-29 and Table 4-20.
The maximum length of this information element is four octets.
Bit
80

1 ext.
1 ext.

7

6

5
4
3
2
Progress indicator
0
0
1
1
1
1
Information element identifier
Length of progress indicator contents
Coding0
Locationstandard
Spare
Progress description

1

Octets0

12
34

Figure 4-29/B-IF2.02(Q.931)
Progress indicator information element

B-IF2.02-02-TS

65

Table 4-20/B-IF2.02(Q.931)
Progress indicator information element
Coding standard (octet 3)
Bit
7 6
0 0
0 1
1 0
1 1

ITU-T standardized coding, as described below
ISO/IEC standard (Note )National standard (Note )Standard specific to identified location (Note )Note :

These other coding standards should be used only when the desired progress indication can not be
represented with the ITU-T-standardized coding.

Location (octet 3)Bit
4 3 2 10 0 0 00 0 1 00 0 1 10 1 0 00 1 0 11 0 1 0User
Public network serving the local user
Transit network (Note 1)
Public network serving the remote user
Private network serving the remote user
Network beyond the interworking point

All other values are reserved.
Note 1: This value may be generated by some networks.
Note 2: Depending on the location of the users, the local public network and remote public network may be
the same network.
Note 3: Public cell station is public network serving the local user.
Progress description (octet 4)Bit
7 6 5 4 3 2 1
0 0 0 0 0 0 1

No.
1.

Call is not end-to-end ISDN; further call progress information may be

0 0 0 0 0 1 0
0 0 0 0 0 1 1
0 0 0 0 1 0 0
0 0 0 0 1 0 1
0 0 0 1 0 0 0

2.
3
4.
5.
8.

Destination address is non ISDN
Origination address is non ISDN
Call has returned to the ISDNInterworking has occurred and has resulted in a telecommunication\
In-band information or an appropriate pattern is now available.

All other values are reserved.
Note 1: This progress description value shall be used only in the case of interworking in a full ISDN
environment, e.g. when bearer capability selection is not supported or when resource or route of thepreferred capability is not available. In case of interworking with a non-ISDN environment a
progress description No. 1 shall be used. If the destination address is non-ISDN, the progressdescription No. 2 shall be used.
Note 2: Interwork with PHS system is regarded ISDN.

66

B-IF2.02-02-TS

4.5.24 Repeat indicator
The purpose of the Repeat indicator information element is to indicate how repeated information
elements shall be interpreted, when included in a message. The Repeat indicator information element
is included before the first occurrence of the information element which will be repeated in a message.
The Repeat indication information element is coded as shown in Figure 4-30 and Table 4-21.
The length of this information element is one octet.
Note : Use of the Repeat indicator information element in conjunction with an information elementthat occurs only once in a message shall not of itself constitute an error.

Bit
8
1

7

6
5
Repeat indicator101Information element
identifier

4

3

2

1

OctetsRepeat indication

1

Figure 4-30/ B-IF2.02(Q.931)
Repeat indicator information element

Table 4-21/ B-IF2.02(Q.931)
Repeat indicator information element
Repeat indication (octet 1)
Bit
4 3 2 10 0 1 0Prioritized list for selecting one possibility

All other values are reserved.

B-IF2.02-02-TS

67

4.5.25 Restart indicator
The purpose of the Restart indicator information element is to identify the class of the facility (i.e.
channel or interface) to be restarted.
The Restart indicator information element is coded as shown in Figure 4-31 and Table 4-22.
The maximum length of this information element is three octets.
Bit
8

7

0

1

1 ext.

0

6

5

4
3
Restart indicator11
10
Information element identifier
Length of restart indicator contents
0
0
0

2

1

Octets

0

1

1

Class

2
3

Figure 4-31/B-IF2.02(Q.931)
Restart indicator information element

Table 4-22/ B-IF2.02(Q.931)
Restart indicator information element
Class (octet 3)
Bit
3 2 1
0 0 0
1 1 0
1 1 1

Indicated channels (Note 1)
Single interface (Note 2)
All interfaces (Note 3)

All other values are reserved.
Note 1:
Note 2:
Note 3:68

The channel identification information element must be included and indicates which channels
are to be restarted.
If non-associated signalling is used, the channel identification information element must be
included to indicate the interface to be restarted if it is other than the one on which the D-channel
is present.
May be used when there are two or more interfaces controlled by the D-channel. The channel
identification information element must not be included with this coding.

B-IF2.02-02-TS

4.5.26 Segmented message
The purpose of the Segmented message information element is to indicate that the transmission inwhich it appears is part of a segmented message, in addition to the use of message type SEGMENT.
When included in a message segment, it appears directly after the Message type information element(see Annex H).
The Segmented message information element is coded as shown in Figure 4-32 and Table 4-23.
The length of this information element is four octets.
Bit
8

7

0

0

6

5

4
3
Segmented message00
00Information element identifier
Length of segmented message contentsFirst
segment
indicator021

Octets

0

0

1
2
3

Number of segments remaining
Segmented message type4

Figure 4-32/ B-IF2.02(Q.931)
Segmented message information element

Table 4-23/B-IF2.02(Q.931)
Segmented message information element
First segment indicator (octet 3)
Bit
8
0
1

Subsequent segment to first segment
First segment of segmented message

Number of seguments remaining (octet 3)
Binary number indicating the number of remainig seguments within the message to sent.
Segmented message type (octet 4)
Type of message being segmented coded as per 4.4
Note :

Bit 8 is reserved for possible future use as an extension bit.

B-IF2.02-02-TS

69

4.5.27 Sending complete*
4.5.28 Signal*
4.5.29 Transit network selection*
4.5.30 User-user*
4.6 Information element for packet communications *70

B-IF2.02-02-TS

5. Circuit-switched call control proceduresThis clause provides the D-channel signalling procedures in support of circuit-mode bearercapabilities other than multirate.
The call states referred to in this clause cover the states perceived by the ISDN, states perceived by the
Public CS, and states which are common to both Public CS and ISDN. Unless specifically qualified,
all states described in the following text should be understood as common (see 2.1.1 and 2.1.2 for
Public CS and ISDN call states respectively). An overview diagram of call states is given in Figures
A.2 and A.3 (see Annex A).
Detailed specification and description language (SDL) diagrams for the procedures specified in thisclause are contained in Figures A.4 through A.6. When there is an ambiguity in the narrative text, theSDL diagrams in Figures A.4 through A.6 should be used to resolve the conflict. Where the text andthe SDL are in disagreement, the text should used as the prime source.
Note 1:This clause describes the sequences of messages associated with the control of circuitswitched connections. Optional extensions to this basic protocol and exceptions that apply
in the case of packet-mode connections or supplementary services are described elsewherein this Recommendation, in Recommendation Q.932 [4] or the Q.95x-Series
Recommendations [83].

All messages in this Recommendation may contain functional information element. Functional
information elements are characterized as requiring a degree of intelligent processing by the Public CS
in either their generation or analysis. Stimulus information elements, on the other hand, are either
generated as a result of a single event at the Public CS/terminal interface or contain a basic instruction
from the ISDN to be executed by the terminal.
In order to accommodate the transfer of Layer 3 messages which exceeds the data link layer maximum
frame length (i.e. defined in Recommendation Q.921 [3]), a method of message segmentation andreassembly may optionally be implemented as described in Annex H. Message segmentation shall
only be used where all the information comprising the unsegmented message is available at the timeof sending the first message segment.
Note 3:Message segmentation is not used to replace existing procedures where information is yet
to be provided by call control, e.g. digit by digit sending in overlap mode, although thismay be used in addition. Message segmentation shall only be used when the message
length exceeds the value of the N201 parameter defined in Recommendation Q.921 [3].

5.1 Call establishment at the originating interface
Before these procedures are invoked, a reliable data link connection must be established between the
Public CS and the ISDN. All layer 3 messages shall be sent to the data link layer using a DL-DATA
request primitive. The data link services described in Recommendations Q.920/I.440 [45] and Q.921[3] are assumed.

B-IF2.02-02-TS

71

5.1.1 Call request
A Public CS initiates call establishment by transferring a SETUP message across the Public CS-ISDN
interface. Following the transmission of the SETUP message, the call shall be considered by the
Public CS to be in the call initiated state. The message shall always contain a call reference, selectedaccording to the procedures given in 4.3. The bearer capability information element is mandatory in
the SETUP message.
If the Public CS knows all appropriate channels controlled by the D-channel are in use, it shall nottransfer a SETUP message across the Public CS-ISDN interface.
Furthermore the SETUP message may also contain all or part of the call information (i.e. address andfacility requests) necessary for call establishment depending.
The SETUP message shall contain all the information required by the ISDN to process the call, and, inparticular, the called party address information if present, is contained as follows:a) in the called party number information element possibly completed by the called party subaddress
information element;
Called party subaddress information, if present, shall be given in the Called party subaddress
information element.
5.1.2 B-channel selection - Originating
In the SETUP message, the Public CS will indicate one of the following:a) channel is indicated, no acceptable alternative [i.e. channel is indicated by the information
channel selection field of octet 3 (bits 2-1) and, if applicable, octet 3.3, and thepreferred/exclusive field (bit 4 of octet 3) is set to “1” in the Channel identification information
element]; orb) channel is indicated, any alternative is acceptable [i.e. channel is indicated by the information
channel selection field of octet 3 (bits 2-1) and, if applicable, octet 3.3, and thepreferred/exclusive field (bit 4 of octet 3) is set to “0” in the Channel identification information
element]; orc) any channel is acceptable [i.e. either the information channel selection field of octet 3 (bits 2-1) of
the Channel identification information element indicate “any channel” or the Channel
identification information element is not present].
If no indication is included, alternative c) is assumed. In cases a) and b), if the indicated channel isavailable, the ISDN selects it for the call.
In case b), if the ISDN cannot grant the preferred channel, it selects any other available B-channel
associated with the D-channel. In case c), the ISDN selects any available B-channel associated with
the D-channel.

72

B-IF2.02-02-TS

The selected B-channel is indicated in the Channel identification information element coded as“channel is indicated, no acceptable alternative” in the first message returned by the ISDN in responseto the SETUP message (i.e. CALL PROCEEDING message). After transmitting this message, the
ISDN shall activate the B-channel connection.
The Public CS need not attach until receiving a CALL PROCEEDING/PROGRESS/ALERTING
message with the progress indicator No. 8, in-band information or appropriate pattern is now
available or progress indication No. 1, call is not end-to-end ISDN; further call progress information
may be available in-band. Prior to this time, the ISDN cannot assume that the Public CS has attachedto the B-channel. After this time, the Public CS shall be connected to the B-channel, provided theequipment does not generate local tone. Upon receipt of the CONNECT message the Public CS shallattach to the B-channel (if it has not already done so).
In case a) if the specified channel is not available, and in cases b) and c) if no channel is available, a
RELEASE COMPLETE message with cause No. 44, requested circuit/channel not available or No.
34, no circuit/channel available, respectively, is sent by the ISDN as described in 5.3.
In case a), if the specified channel does not exist, cause No. 82, identified channel does not exist is
included in the RELEASE COMPLETE message.
5.1.3 Overlap sending*
5.1.4 Invalid call informationIf, following the receipt of a SETUP message or during overlap sending, the ISDN determines that thecall information received from the Public CS is invalid, (e.g. invalid number), then the ISDN shallfollow the procedures described in 5.3 with a cause such as one of the following:
No. 1
No. 3
No. 22
No. 28- Unassigned (unallocated) number;- No route to destination;- Number changed;- Invalid number format (incomplete number).

5.1.5 Call proceeding
5.1.5.1 Call proceeding
If the ISDN can determine that the SETUP message contains all the information required from the
Public CS to establish the call and if the ISDN can determine that access to the requested service isauthorized and available, the ISDN shal send a CALL PROCEEDING message to the Public CS. Thisacknowledges the SETUP message, and indicates that the call is being processed. The ISDN will thenenter the Outgoing Call Proceeding state. When the Public CS receives the CALL PROCEEDING
message, the Public CS shall also enter the Outgoing Call Proceeding state.
Similarly, if the ISDN determines that a requested service is not authorized or is not available, the
ISDN shall initiate call clearing in accordance with 5.3, with one of the following causes:
No. 57 - Bearer capability not authorized;

B-IF2.02-02-TS

73

No. 58 - Bearer capability not presently available;
No. 63 - Service or option not available, unspecified; orNo. 65 - Bearer service not implemented.
Note 1:
Note 2:

If a supplementary service is not authorized or is not available, the procedure to be used isdefined in the supplementary service control procedures.
When the ISDN cannot assign a channel due to congestion, the procedures of 5.1.2 shall befollowed.

5.1.5.2 Call proceeding, overlap sending*
5.1.6 Notification of interworking at the originating interface
During call establishment, the call may leave the ISDN environment, e.g. because of interworking
with another ISDN, with a non-ISDN Public CS, or with non-ISDN equipment within the called
Public CS’s premises. When such situations occur a progress indication shall be returned to the calling
Public CS either:a) in an appropriate call control message when a state change is required: CALL PROCEEDING,ALERTING, SETUP ACKNOWLEDGE or CONNECT; orb) in the PROGRESS message when no state change is appropriate.
One of the following progress description values shall be included in the Progress indicator
information element in the messages sent to the Public CS, (for further information see Annex G).
1) No. 1 - Call is not end-to-end ISDN; further call progress information may be available in-band;2) No. 2 - Destination address is non-ISDN;
3) No. 4 - Call has returned to the ISDN.
If the Progress indicator information element is included in a call control message, the procedures as
described in the rest of 5.1 apply. If the Progress indicator information element is included in the
Progress message, no state change will occur but any supervisory timers shall be stopped except ISDN
timer T302. In both cases, if indicated by the Progress indicator information element, the Public CS
shall connect to (if not connected already) and then monitor the B channel for further in-band
information.
If the interface at which the progress indication originates is the point at which a call enters the ISDN
environment from a non-ISDN environment, one or more of the following progress indicator
information elements shall be included in the SETUP message sent to the ISDN:i) No. 1 - Call is not end-to-end ISDN; further call progress information may be available in-band;ii) No. 3 - Origination address is non-ISDN.
5.1.7 Call confirmation indication
Upon receiving an indication that alerting has been initiated at the destination, the ISDN shall send an
ALERTING message across the Public CS-ISDN interface of the calling address, and shall enter the74

B-IF2.02-02-TS

call delivered state. When the Public CS receives the ALERTING message, the Public CS may begin
an internally-generated alerting indication and shall enter the call delivered state.
5.1.8 Call connected
Upon the ISDN receiving an indication that the call has been accepted at the destination, the ISDN
shall send a CONNECT message across the Public CS-ISDN interface, and shall enter the Active
state. As a ISDN option, the Date/time information element may be included in the CONNECT
message.
This message indicates to the calling Public CS that a connection has been established through the
ISDN and stops a possible local indication of alerting.
On receipt of the CONNECT message, the originating Public CS shall stop any Public CS-generated
alerting indications; may optionally send a CONNECT ACKNOWLEDGE message, and shall enter
the active state. The ISDN shall not take any action on receipt of a CONNECT ACKNOWLEDGE
message when it perceives the call to be in the active state.
5.1.9 Call rejection
Upon receiving an indication that the ISDN or the destination is unable to accept the call, the ISDN
shall initiate call clearing at the originating Public CS-ISDN interface as described in 5.3, using thecause provided by the ISDN or the destination.
5.1.10 Transit ISDN selection*
5.2 Call establishment at the destination interface
This procedure assumes that a data link connection providing services described in Recommendation
Q.920/I.440 [45] may not exist before the first layer 3 message (SETUP) is transferred across theinterface. However, reliable data link connections must be established by each of the Public CSs at theinterface before they respond to the SETUP message.
Data link connections may be established by the TA, TE or NT2 as soon as a TEI is assigned (either
locally or by automatic assignment procedure), and may be retained indefinitely. This may berecommended as a ISDN option.
The SETUP message offered on a point-to-point data link shall be delivered to layer 2 using a DLDATA request primitive.
The call reference contained in all messages exchanged across the Public CS-ISDN interface shallcontain the call reference value specified in the SETUP message delivered by the ISDN.
5.2.1 Incoming call
The ISDN will indicate the arrival of a call at the Public CS-ISDN interface by transferring a SETUP
message across the interface. This message is sent if the ISDN can select an idle B-channel. The
SETUP message may also be sent when no B-channel is idle.

B-IF2.02-02-TS

75

In addition to the mandatory information elements, the SETUP message may include, as required, theinformation elements described in 3.1.14.
After sending the SETUP message, the ISDN starts timer T303 and timer T312. (The values of timers
T303 and T312 are specified in 9.1.) The ISDN then enters the call present state.
Note 1:

Timer T312 is used to supervise the retention of the call reference. The value of timer
T312 is such that if a ISDN disconnect indication is received during the call establishment
phase, it maximizes the probability that all responding Public CSs will be released prior torelease of the call reference. Refer to 5.3.2 e) and 5.2.5.3 (Case 1) for procedures to befollowed on expiry of timer T312.

The SETUP message may contain the Sending complete information element.
Upon receipt of a SETUP message, the Public CS will enter the Call present state.
If no response to the SETUP message is received by the ISDN before the first expiry of timer T303,
the SETUP message will be retransmitted and timers T303 and T312 restarted.
5.2.2 Compatibility checking
A destination receiving a SETUP message shall perform compatibility checking before responding tothat SETUP message. Annex B defines compatibility checking to be performed by Public CSs uponreceiving a SETUP message.
When the SETUP message is delivered, an incompatible Public CS shall respond with RELEASECOMPLETE message with cause No.65, bearer capability not implemented, or with cause No. 88,
incompatible destination, and enter the Null state. The ISDN shall process this RELEASECOMPLETE message in accordance with 5.2.5.3.
5.2.3 B-channel selection - Destination
When the SETUP message is delivered by a point-to-point data link, negotiation for the selection of a
B-channel will be permitted between the ISDN and the Public CS. Only B-channels controlled by thesame D-channel will be the subject of the selection procedure. The selection procedure is as follows:a) In the SETUP message, the ISDN will indicate one of the following:
1) channel is indicated, no acceptable alternative [i.e. channel is indicated by the information
channel selection field of octet 3 (bits 2-1) and, if applicable, octet 3.3, and thepreferred/exclusive field (bit 4 of octet 3) is set to “1” in the Channel identification
information element]; or2) any channel is acceptable [i.e. either the information channel selection field of octet 3 (bits 21) of the Channel identification information element indicate “any channel” or the Channel
identification information element is not present]; or76

B-IF2.02-02-TSb) In case 1) , if the indicated channel is acceptable and available, the Public CS selects it for thecall.
In case 2), the Public CS selects any available B-channel associated with the D-channel, andidentifies that channel in the first message sent in response to the SETUP message.
If in case 1) the B-channel indicated in the first response message is not the channel offered by the
ISDN, or in case 2) the B-channel indicated in the first response message is unacceptable to the
ISDN, it will clear the call by sending a RELEASE message with cause No. 6, channel
unacceptable.
c) If no Channel identification information element is present in the first response message, the Bchannel indicated in the SETUP message will be assumed.
d) When a B-channel has been selected by the Public CS, that channel may be connected by the
Public CS.
e) In case 1) if the indicated B-channel is not available, or in cases 2), 3), and 4) if no B-channel isavailable and the Public CS cannot proceed with the offered call, the Public CS returns a
RELEASE COMPLETE message with cause No. 44 requested circuit/channel not available orNo. 34 no circuit/channel available, respectively, and returns to the Null state.
5.2.4 Overlap receiving*
5.2.5 Call confirmation
5.2.5.1 Response to SETUP
When the Public CS determines that sufficient call set-up information has been received andcompatibility requirements have been satisfied, the Public CS responds with a CALL PROCEEDING,
and enters the Incoming Call Proceeding state.
Note :A Progress indicator information element may be included in CALL PROCEEDING,ALERTING and CONNECT messages (e.g. when an analogue terminal is connected to an
ISDN PABX).

If the Public CS which has checked the existence of PS confirmed the incompatibility of bearercapability information element of SETUP message, a RELEASE COMPLETE message shall be sentwith the cause No. 65, Bearer capability not implemented, to the ISDN. The ISDN processes thisRELEASE COMPLETE message in accordance with 5.2.5.3. The Public CS which does notrecognize the existence of PS shall ignore the SETUP message.
If the Public CS wishes to refuse the call while the Public CS confirm end-to-end call connection, a
RELEASE COMPLETE message shall be sent with the cause No. 21, call rejected, and the Public CS
returns to the Null state.
The ISDN processes these RELEASE COMPLETE messages in accordance with 5.2.5.3.

B-IF2.02-02-TS

77

Public CS which could not confirm end-to-end call connection shall ignore the SETUP message.
5.2.5.2 Receipt of CALL PROCEEDING and ALERTING
Upon receipt of the first CALL PROCEEDING message from a Public CS, the ISDN shall stop timer
T303; start timer T310, and enter the incoming call proceeding state.
When the SETUP message has been delivered on a broadcast data link, the ISDN shall associate theincoming call proceeding state with each called Public CS that sends a CALL PROCEEDING
message as a first response to the broadcast SETUP message prior to expiration of timer T312.
Actions to be taken when a Public CS sends a first response to an incoming call after the expiration oftimer T312 are described in 5.2.5.4. Timer T310 shall not be restarted.
Upon receipt of the first ALERTING message from a Public CS, the ISDN shall stop T310 (ifrunning); start timer T301 (unless another internal alerting supervision timer function exists, e.g.
incorporated in call control); enter the call received state, and send a corresponding ALERTING
message to the origination.
The ISDN shall associate the call received state with each called Public CS that sends an ALERTING
message following a CALL PROCEEDING message.
5.2.5.3 Clearing of destination Public CS during SETUP at the destination
Upon receiving a RELEASE COMPLETE message before timer T303 is expired, the ISDN shallinitiate clearing the Public CS.
Upon receiving a DISCONNECT or RELEASE, RELEASE COMPLETE message before receiving
CONNECT message from the Public CS that is checked compatibility, the ISDN shall initiate clearingof the call.
Upon receiving a DISCONNECT or RELEASE, RELEASE COMPLETE message before receiving
CONNECT message from the Public CS that is checked compatibility, the digital ISDN shall initiate
clearing of the Public CS.
When the timer T303 is expired (that is, no valid message, like CALL PROCEEDING, is received),
the ISDN shall enter the Call Abort state.

78

B-IF2.02-02-TS

5.2.5.4 Call failure
If the ISDN does not receive any response to the retransmitted SETUP message prior to the expirationof timer T303, then the ISDN shall initiate clearing procedures towards the origination with cause No.
20, subscriber absent.
If the ISDN receives a Public CS’s first response to SETUP when in the Call Abort state but before
timer T312 has expired, the ISDN shall initiate clearing to the called Public CS as described in 5.3.2b), except that the cause No. 102, recovery on timer expiry shall be sent. If the ISDN receives amessage that is a Public CS’s first response to an incoming call after timer T312 has expired, the
ISDN will interpret this message as a message received with an invalid call reference value, as
described in 5.8.3.2.
If the ISDN has received a CALL PROCEEDING message, but does not receive an ALERTING,
CONNECT, or DISCONNECT message prior to the expiration of timer T310, then the ISDN shallinitiate clearing procedures towards the origination with cause No. 18, no Public CS responding andinitiate clearing procedures towards the called Public CS. If the SETUP message is delivered by abroadcast data link, the called Public CS shall be cleared in accordance with 5.3.2 e), except that cause
No. 102, recovery on timer expiry shall be sent.

If the ISDN has received an ALERTING message, but does not receive a CONNECT or
DISCONNECT message prior to the expiry of timer T301 (or a corresponding internal alerting
supervision timing function), then the ISDN shall initiate clearing procedures towards the origination
with cause No. 19, Public CS alerting, no answer; and initiate clearing procedures towards the called
Public CS. If the SETUP message was delivered by a broadcast data link, the called Public CS shall becleared in accordance with 5.3.2 e), except that cause No. 102, recovery on timer expiry shall be sent.
5.2.6 Notification of interworking at the terminating interface
During call establishment the call may enter an ISDN environment, e.g. because of interworking withanother ISDN, with a non-ISDN Public CS, or with non-ISDN equipment within the calling or called
Public CS’s premises. When this occurs, the point at which the call enters an ISDN environment shallcause a Progress indicator information element to be included in the SETUP message to be sent to thecalled Public CS:a) No. 1 “call is not end-to-end ISDN; further call progress information may be available in-band”;
Note :On receipt of progress indicator No. 1, the called Public CS shall connect tothe B-channel in accordance with the procedures of 5.2.8.

b) No. 3 “origination address is non-ISDN”.
In addition, the Public CS shall notify the calling party if the call has left the ISDN environment
within the called Public CS’s premises, or upon the availability of in-band information/patterns. Whensuch situations occur, a progress indication shall be sent by the Public CS to the ISDN either

B-IF2.02-02-TS

79a) in an appropriate call control message when a state change is required (CALL PROCEEDING,ALERTING, or CONNECT); orb) in the PROGRESS message when no state change is appropriate.
One of the following progress description values shall be included in the Progress indicator
information element in the message sent to the ISDN (for further information, see Annex G):
i)

No. 1 - Call is not end-to-end ISDN; further call progress information may be available inband;ii) No. 2 - Destination address is non-ISDN;iii) No. 4 - Call has returned to the ISDN.

If the progress indicator information element is included in a call control message, the procedures as
described in the rest of 5.2 apply. If the progress indicator information element is included in the
PROGRESS message, no state change will occur but any supervisory timers shall be stopped except
ISDN timer and T312.
5.2.7 Call accept
A Public CS indicates acceptance of an incoming call by sending a CONNECT message to the ISDN.
Upon sending the CONNECT message the Public CS shall start timer T313 (specified in 9.2). If an
ALERTING message had previously been sent to the ISDN, the CONNECT message may contain
only the call reference.
If a call can be accepted using the B-channel indicated in the SETUP message, and no alerting isrequired, a CONNECT message may be sent without a previous ALERTING message.
5.2.8 Active indication
On receipt of the first CONNECT message, the ISDN shall stop (if running) timers T301 and T310;
complete the circuit-switched path to the selected B-channel; send a CONNECT ACKNOWLEDGE
message to the Public CS which first accepted the call; initiate procedures to send a CONNECT
message towards the origination, and enter the active state.
The CONNECT ACKNOWLEDGE message indicates completion of the circuit-switched connection.
There is no guarantee of an end-to-end connection until a CONNECT message is received at theorigination. Upon receipt of the CONNECT ACKNOWLEDGE message the Public CS shall stop
timer T313 and enter the active state.
When timer T313 expires prior to receipt of a CONNECT ACKNOWLEDGE message, the Public CS
shall initiate clearing in accordance with 5.3.3.
A Public CS which has selected channel may connect to the B-channel as soon as channel selection
has been completed.

80

B-IF2.02-02-TS

5.2.9 Call procedure for the grouped multiple interfaces[moved to Appendix IV]
5.3 Call clearing
5.3.1 Terminology
The following terms are used in this Recommendation in the description of clearing procedures:-

A channel is connected when the channel is part of a circuit-switched ISDN connection
established according to this Recommendation.
A channel is disconnected when the channel is no longer part of a circuit-switched ISDN
connection, but is not yet available for use in a new connection.
A channel is released when the channel is not part of a circuit-switched ISDN connection
and is available for use in a new connection. Similarly, a call reference that is released isavailable for reuse.

5.3.2 Exception conditions
Under normal conditions, call clearing is usually initiated when the Public CS or the ISDN sends a
DISCONNECT message and follows the procedures defined in 5.3.3 and 5.3.4 respectively. The only
exceptions to the above rule are as follows:a) In response to a SETUP message, the Public CS or ISDN can reject a call (e.g. because of theunavailability of a suitable B-channel) by responding with a RELEASE COMPLETE message
provided no other response has previously been sent (e.g. the SETUP ACKNOWLEDGE message
in the case of overlap sending); releasing the call reference, and enter the Null state.
b) In the case of a multipoint terminal configuration, non-selected Public CS call clearing will be
initiated with RELEASE message(s) from the ISDN (see 5.2.9).
c) [non-standard]d) Unsuccessful termination of the B-channel selection procedure (see 5.2.3.1 and 5.1.2) by the side
offering the call is accomplished by sending a RELEASE message. The RELEASE message shallcontain cause No. 6, channel unacceptable. The ISDN and Public CS shall subsequently follow
the procedures of 5.3.3 and 5.3.4.
e)

1)

In the case of a SETUP message sent via the broadcast data link, if a ISDN disconnect
indication is received during call establishment, and prior to the expiry of timer T312, timer
T303 is stopped (if running) and the ISDN enters the Call Abort state. Any Public CS
which has responded, or subsequently responds before timer T312 expires, will be cleared
by a RELEASE message (with the cause code(s) contained in the ISDN disconnect
indication) and the procedures of 5.3.4 are then followed for that Public CS. Upon expiryof timer T312, the ISDN shall treat any subsequent responses according to the procedures
defined in 5.8.3.2. The ISDN shall enter the Null state upon completion of clearing
procedures for all responding Public CSs.

B-IF2.02-02-TS

81

2)

In the case of a SETUP message sent via the broadcast data link, if a ISDN disconnect
indication is received during call establishment after expiry of timer T312, any Public CS
which has responded shall be cleared by a RELEASE message (with the cause code(s)contained in the ISDN disconnect indication) and the procedures of 5.3.4 are then followed
for that Public CS. The ISDN enters the Null state upon completion of clearing procedures
for all responding Public CSs.

5.3.3 Clearing initiated by the Public CS
Apart from the exceptions identified in 5.3.2 and 5.8, the Public CS shall initiate clearing by sending a
DISCONNECT message; starting timer T305 (the value of timer T305 is specified in 9.2);
disconnecting the B-channel, and entering the disconnect request state.
Note :

When a Public CS initiates call clearing by sending a RELEASE message, the procedures
described in 5.3.4 are then followed.

The ISDN shall enter the Disconnect Request state upon receipt of a DISCONNECT message. Thismessage then prompts the ISDN to disconnect the B-channel, and to initiate procedures for clearing
the ISDN connection to the remote side. Once the B-channel used for the call has been disconnected,
the ISDN shall send a RELEASE message to the Public CS; start timer T308 (the value of a timer
T.308 is specified in 9.1), and enter the Release Request state.
Note :The RELEASE message has only local significance and does not imply an
acknowledgement of clearing from the remote side.

On receipt of the RELEASE message the Public CS shall cancel timer T305; release the B-channel;
send a RELEASE COMPLETE message; release the call reference; and return to the Null state.
Following the receipt of a RELEASE COMPLETE message from the Public CS, the ISDN shall stop
timer T308; release both the B-channel and the call reference, and return to the Null state.
If timer T305 expires, the Public CS shall send a RELEASE message to the ISDN with the cause
number originally contained in the DISCONNECT message; start timer T308 and enter the Release
Request state. In addition, the Public CS may indicate a second Cause information element with cause
No. 102, recovery on timer expiry.
If timer T308 expires for the first time, the ISDN shall retransmit the RELEASE message andtimer T308 shall be restarted. In addition, the ISDN may indicate a second Cause information elementwith cause No. 102, recovery on timer expiry. If no RELEASE COMPLETE message is received fromthe Public CS before timer T308 expires a second time, the ISDN shall place the B-channel in a
maintenance condition, release the call reference, and return to the Null state.
Note 1:
Note 2:

The restart procedures contained in 5.5 may be used on B-channels in the maintenancecondition.
Other actions which could be taken by the ISDN upon receipt of a DISCONNECT
message are for further study.

The actions to be taken with regard to the maintenance condition are ISDN dependent.

82

B-IF2.02-02-TS

5.3.4 Clearing initiated by the ISDN
Apart from the exception conditions identified in 5.3.2 and 5.8, the ISDN shall initiate clearing bysending a DISCONNECT message, and entering the Disconnect Indication state. The DISCONNECT
message is a local invitation to clear and does not imply that the B-channel has been disconnected at
the Public CS-ISDN interface.
Note :

When the ISDN initiates clearing by sending a RELEASE message, the procedures
described in 5.3.3 are followed.

5.3.4.1 Clearing when tones/announcements provided
When in-band tones/announcements are provided (see 5.4), the DISCONNECT message contains
progress indicator No. 8, in-band information or appropriate pattern now available. The ISDN shall:
start timer T306; and enter the Disconnect Indication state.
On receipt of the DISCONNECT message with progress indicator No. 8, the Public CS may connect(if not already connected) to the B-channel to receive the in-band tone/announcement; and enter the
disconnect indication state. Alternatively, to continue clearing without connecting to the in-bandtone/announcement, the Public CS shall disconnect the B-channel; send a RELEASE message, start
timer T308, and enter the Release Request state.
If the Public CS connects to the provided in-band tone/announcement, the Public CS may
subsequently continue clearing (before the receipt of a RELEASE from the ISDN) by disconnectingfrom the B-channel; sending a RELEASE message; starting timer T308; and entering the Release
Request state.
On receipt of the RELEASE message, the ISDN shall stop timer T306; disconnect and release the Bchannel; send a RELEASE COMPLETE message; release the call reference, and return to the Nullstate.
If timer T306 expires, the ISDN shall continue clearing by disconnecting the B-channel; sending a
RELEASE message with the cause number originally contained in the DISCONNECT message;
starting timer T308, and entering the Release Request state.
In addition to the original clearing cause, the RELEASE message may contain a second cause
information element with cause No. 102, recovery on timer expiry; this cause may optionally contain adiagnostic field identifying the timer that expired.
On receipt of the RELEASE message, the Public CS shall act according to 5.3.3.
5.3.4.2 Clearing when tones/announcements not provided
When in-band tones/announcements are not provided, the DISCONNECT message does not containprogress indicator No. 8 in-band information or appropriate pattern now available. The ISDN shallinitiate clearing by sending the DISCONNECT message; start timer T305; disconnects the B-channel,
and enters the Disconnect Indication state.

B-IF2.02-02-TS

83

On the receipt of the DISCONNECT message without progress indicator No. 8, the Public CS shalldisconnect the B-channel; send a RELEASE message; start timer T308, and enter the Release Request
state.
On receipt of the RELEASE message, the ISDN shall stop timer T305; release the B-channel; send a
RELEASE COMPLETE message; release the call reference, and return to the Null state.
If timer T305 expires, the ISDN shall send a RELEASE message to the Public CS with the cause
number originally contained in the DISCONNECT message; start timer T308, and enter the Release
Request state. In addition to the original clearing cause, the RELEASE message may contain a second
Cause information element with cause No. 102, recovery on timer expiry.
5.3.4.3 Completion of clearing
Following the receipt of a RELEASE COMPLETE message from the ISDN, the Public CS shall stop
timer T308; release both the B-channel and the call reference, and return to the Null state.
If a RELEASE COMPLETE is not received by the Public CS before the first expiry of timer T308, the
RELEASE message shall be retransmitted and timer T308 shall be restarted. If no RELEASECOMPLETE message is received from the ISDN before timer T308 expires a second time, the Public
CS may place the B-channel in a maintenance condition; shall release the call reference, and return to
the Null state.
Note :The restart procedures contained in 5.5 may be used on B-channels in the maintenancecondition.

5.3.5 Clear collision
Clear collision occurs when the Public CS and the ISDN simultaneously transfer DISCONNECT
messages specifying the same call reference value. When the ISDN receives a DISCONNECT
message whilst in the Disconnect Indication state, the ISDN shall stop timer T305 or T306 (whicheveris running); disconnect the B-channel (if not disconnected); send a RELEASE message; start timer
T308, and enter the Release Request state. Similarly, when the Public CS receives a DISCONNECT
message whilst in the Disconnect Request state, the Public CS shall stop timer T305; send a
RELEASE message; start timer T308, and enter the Release Request state.
Clear collision can also occur when both sides simultaneously transfer RELEASE messages related tothe same call reference value. The entity receiving such a RELEASE message whilst within the
Release Request state shall stop timer T308; release the call reference and B-channel, and enter the
Null state (without sending or receiving a RELEASE COMPLETE message).
5.4 In-band tones and announcements
When in-band tones/announcements not associated with a call state change are to be provided by the
ISDN before reaching the Active state, a PROGRESS message is returned simultaneously with theapplication of the in-band tone/announcement. The PROGRESS message contains the progress
indicator No. 8, in-band information or appropriate pattern is now available.

84

B-IF2.02-02-TS

When tones/announcements have to be provided together with a call state change, then the appropriate
message [e.g. for ALERTING, DISCONNECT, etc., (see appropriate section)] with progress indicator
No. 8, in-band information or appropriate pattern is now available is sent simultaneously with theapplication of the in-band tone/announcement.
Note 1:

Note 2:
Note 3:

When the ISDN provides CCITT standardized telecommunications services, the service
requirement for provision of in-band tones/announcements is as indicated in the I.200Series Recommendations.
When the PROGRESS message is used, the Public CS may initiate call clearing as a resultof the applied in-band tone/announcement, according to the procedures specified in 5.3.3.
The protocol currently described in 5.4 applies at the calling Public CS-ISDN interface.
The protocol to be applied at the interISDN interface and at the called Public CS-ISDN
interface requires further study.

5.5 Restart procedure
The restart procedure is used to return calls to the Null state or the interface to an idle condition. The
procedure is usually invoked when the other side of the interface does not respond to other call control
messages or a failure has occurred (e.g. following a data link failure, when a backup D-channel can beused, or following the expiry of timer T308 due to the absence of response to a clearing message). It
may also be initiated as a result of local failure, maintenance action or mis-operation.
Note 1:
Note 2:

Layer 3 procedures and resources associated with those data links with SAPI = “0000 000”should be initialized by the restart procedures.
The call reference flag of the global call reference applies to restart procedures. In the casewhen both sides of the interface initiate simultaneous restart requests, they shall be handledindependently. In the case when the same channel(s) or interface(s) are specified, they shallnot be considered free for reuse until all the relevant restart procedures are completed.

5.5.1 Sending RESTART message
A RESTART message is sent by the ISDN or Public CS equipment in order to return channels orinterfaces to the Null state. The Restart indicator information element shall be present in the
RESTART message to indicate whether an Indicated channel, Single interface or All interfaces are to
be restarted. If the Restart indicator information element is coded as “Indicated channel”, or “Single
interface” and the interface is one other than the one containing the D-channel, then the Channel
identification information element shall be present to indicate which channel or interface is to be
returned to the idle condition. If the Restart indicator information element is coded as “Single
interface” and the interface is the one containing the D-channel, then the Channel identification
information element may be omitted. If the Restart indicator information element is coded as “Allinterfaces” then the Channel identification information element shall not be included.
Upon transmitting the RESTART message the sender enters the Restart Request state, starts
timer T316, and waits for a RESTART ACKNOWLEDGE message. Also, no further RESTART
messages shall be sent until a RESTART ACKNOWLEDGE is received or timer T316 expires.
Receipt of a RESTART ACKNOWLEDGE message stops timer T316, frees the channels and callreference values for reuse, and enters the Null state.

B-IF2.02-02-TS

85

If a RESTART ACKNOWLEDGE message is not received prior to the expiry of timer T316 one ormore subsequent RESTART messages may be sent until a RESTART ACKNOWLEDGE message isreturned. Meanwhile, no calls shall be placed or accepted over the channel or interface by theoriginator of the RESTART message. A ISDN shall limit the number of consecutive unsuccessful
restart attempts to a default limit of two. When this limit is reached, the ISDN shall make no further
restart attempts. An indication will be provided to the appropriate maintenance entity. The channel orinterface is considered to be in an out-of-service condition until maintenance action has been taken.
Note :

If a RESTART ACKNOWLEDGE message is received indicating only a subset of thespecified channels, an indication shall be given to the maintenance entity. It is the
responsibility of the maintenance entity to determine what actions shall be taken on thechannel(s) which have not been returned to the idle condition.

The RESTART and RESTART ACKNOWLEDGE message shall contain the global call reference
value (all zeros) to which the Restart Request state is associated. These messages are transferred via
the appropriate point-to-point data link in the multiple frame mode using the DL-DATA request
primitive.
5.5.2 Receipt of RESTART message
Upon receiving a RESTART message the recipient shall enter the Restart state associated to the global
call reference and start timer T317; it shall then initiate the appropriate internal actions to return thespecified channels to the idle condition and call references to the Null state. Upon completion ofinternal clearing, timer T317 shall be stopped and a RESTART ACKNOWLEDGE message
transmitted to the originator, and the Null state entered.
Note 1:

If only a subset of the specified channels have been returned to the idle condition whentimer T317 expires, a RESTART ACKNOWLEDGE message should be transmitted to theoriginator, containing a Channel identification information element indicating thechannel(s) that have been returned to the idle condition.

If timer T317 expires prior to completion of internal clearing an indication shall be sent to themaintenance entity (i.e. a primitive should be transmitted to the system management entity).
Note 2:

Even if all call references are in the Null state, and all channels are in the idle condition,
the receiving entity shall transmit a RESTART ACKNOWLEDGE message to theoriginator upon receiving a RESTART message.

If the Restart indicator information element is coded as “all interfaces” then all calls on all interfaces
associated with the D-channel shall be cleared. If the Restart indicator information element is coded as“all interfaces” and a Channel identification information element is included, the Channel
identification information element is treated as described in 5.8.7.3.
If the Restart indicator information element is coded as “indicated channel” and the Channel
indication information element is not included, then the procedures in 5.8.6.1 shall be followed.
If the Restart indicator information element is coded as “single interface” and that interface includes
the D-channel then only those calls associated with the D-channel on that interface shall be cleared.

86

B-IF2.02-02-TS

The receiving DSS1 protocol control entity for the global call reference shall indicate a restart request
to only those DSS1 protocol control entities for specific call references whicha) are supported by the same Data Link Connection Endpoint Identifier (DLCI) (see Recommendation Q.920) as the DSS1 protocol control entity for the global call reference which received the
RESTART message; andb) correspond to the specified channel(s) or interface(s), or (if the D-channel was implicitly
specified) are not associated with any channel, including calls in the call establishment phase forwhich a channel has not yet been allocated.
5.6 Call rearrangements*
5.7 Call collisions
Call collisions as such cannot occur at the ISDN. Any simultaneous incoming or outgoing calls aredealt with separately and assigned different call references.
Channel selection conflicts may occur if an incoming call and outgoing call select the same channel.
This is resolved by the ISDN through channel selection mechanisms described in 5.1.2 and 5.2.2.
In the case of such conflicts, the ISDN shall give priority to the incoming call over the call request
received from the Public CS. It shall clear the outgoing call whenever the B-channel cannot be,allocated by the ISDN or accepted by the Public CS originating the call.
5.8 Handling of error conditions
All procedures transferring signalling information by using the protocol discriminator of Q.931 Public
CS-ISDN call control messages are applicable only to those messages which pass the checks
described in 5.8.1 through 5.8.7. The error handling procedures of 5.8.1 through 5.8.7 apply tomessages using an ordinary call reference or the global call reference, except where otherwise noted.
Detailed error handling procedures are implementation dependent and may vary from ISDN to ISDN.
However, capabilities facilitating the orderly treatment of error conditions are provided for in thissection and shall be provided in each implementation.
Subclauses 5.8.1 through 5.8.7 are listed in order of precedence.

B-IF2.02-02-TS87

5.8.1 Protocol discrimination error
When a message is received with a protocol discriminator coded other than Q.931 Public CS-ISDN
call control message, that message shall be ignored, means to do nothing, as if the message had neverbeen received.
5.8.2 Message too short
When a message is received that is too short to contain a complete message type information element,that message shall be ignored.
5.8.3 Call reference error
5.8.3.1 Invalid Call reference format
If the Call reference information element octet 1, bits 5 through 8 do not equal 0000, then the message
shall be ignored.
If the Call reference information element octet 1, bits 1 through 4 indicate a length greater than the
maximum length supported by the receiving equipment (see 4.3), then the message shall be ignored.
5.8.3.2 Call reference procedural errors
Only item f) applies to messages using the global call reference.
a) Whenever any message except SETUP, RELEASE, RELEASE COMPLETE, STATUS or
STATUS ENQUIRY is received specifying a call reference which it does not recognize as
relating to an active call or a call in progress, clearing is initiated by sending a RELEASE
message with cause No. 81, “invalid call reference value” and following the procedures in 5.3,
specifying the call reference in the received message.
Alternatively, the receiving entity may send a RELEASE COMPLETE message withcause No. 81, “invalid call reference value” and remain in the Null state.
b) When a RELEASE message is received that specified a call reference which is not recognized as
relating to an active call or a call in progress, a RELEASE COMPLETE message with cause No.
81, “invalid call reference value” is returned, specifying the call reference in the received
message.
c) When a RELEASE COMPLETE message is received specifying a call reference which it does notrecognize as relating to an active call or a call in progress, no action should be taken.
d) When a SETUP or RESUME message is received specifying a call reference which is recognized
as relating to an active call or to a call in progress, and with a call reference flag incorrectly set to“1”, that message shall be ignored.
e) When a SETUP message is received specifying a call reference which is recognized as relating toan active call, or a call in progress, this SETUP message shall be ignored.

88

B-IF2.02-02-TS

f)

When any message except RESTART, RESTART ACKNOWLEDGE, or STATUS is received
using the global call reference, no action should be taken on this message and a STATUS
message using the global call reference with a call state indicating the current state associatedwith the global call reference and cause No. 81 “invalid call reference value” shall be returned.

g) When a STATUS message is received specifying a call reference which is not recognized as
relating to an active call or to a call in progress, the procedures of 5.8.11 shall apply.
h) When a STATUS ENQUIRY message is received specifying a call reference which is notrecognized as relating to an active call or to a call in progress, the procedures of 5.8.10 shallapply.
5.8.4 Message type or message sequence errors
Whenever an unexpected message, except RELEASE or RELEASE COMPLETE, or unrecognized
message is received in any state other than the Null state, a STATUS message shall be returned withcause No. 98, message not compatible with call state or message type non-existent or not implemented
and the corresponding diagnostic. If a ISDN or Public CS can distinguish between unimplemented (ornon-existent) message types and implemented message types which are incompatible with the callstate, then a STATUS message may be sent with one of the following causes:a) cause No. 97 message type non-existent or not implemented; orb) cause No. 101 message not compatible with call state.
Alternatively, a STATUS ENQUIRY message may be sent requesting the call state of the entity(see 5.8.10). No change in state shall be made in either case at this time. This alternative is notapplicable to messages using the global call reference.
However, two exceptions to this procedure exist. The first exception is when the ISDN or the Public
CS receives an unexpected RELEASE message (e.g. if the DISCONNECT message was corrupted byundetected transmission errors). In this case no STATUS or STATUS ENQUIRY message is sent.
Whenever the ISDN receives an unexpected RELEASE message, the ISDN shall disconnect andrelease the B-channel; clear the ISDN connection and the call to the remote side with the cause in the
RELEASE message sent by the Public CS or, if not included, cause No. 31, normal, unspecified;
return a RELEASE COMPLETE message to the Public CS; release the call reference, stop all timers
and enter the Null state. Whenever the Public CS receives an unexpected RELEASE message, thePublic CS shall disconnect and release the B-channel; return a RELEASE COMPLETE message tothe ISDN; release the call reference; stop all timers, and enter the Null state.
The second exception is when the ISDN or the Public CS receives an unexpected RELEASECOMPLETE message. Whenever the ISDN receives an unexpected RELEASE COMPLETE
message, the ISDN shall disconnect and release the B-channel; clear the ISDN connection and the callto the remote side with the cause indicated by the Public CS or, if not included, cause No. 111,
protocol error, unspecified; release the call reference; stop all timers and enter the Null state.
Whenever the Public CS receives an unexpected RELEASE COMPLETE message, the Public CS
shall disconnect and release the B-channel; release the call reference; stop all timers, and enter the
Null state.

B-IF2.02-02-TS89

5.8.5 General information element errors
The general information element error procedures may also apply to information elements in codesets
other than 0. In that case, the diagnostics in the cause information element may indicate information
elements other than those in codeset 0 by applying the locking or non-locking shift procedures as
described in 4.5.
5.8.5.1 Information element out of sequence
A variable length information element which has a code value lower than the code value of thevariable length information element preceding it shall be considered as an out of sequence information
element.
If the ISDN or Public CS receives a message containing an out of sequence information element, it
may ignore this information element and continue to process the message. If this information is
mandatory, and the ISDN or Public CS chooses to ignore this out of sequence information element,
then the error handling procedure for missing mandatory information elements as described in 5.8.6.1
shall be followed. If the ignored information element is non-mandatory, the receiver continues toprocess the message.
Note :

Some implementations may choose to process all the information elements received in a
message regardless of the order in which they are placed.

5.8.5.2 Duplicated information elements
If an information element is repeated in a message in which repetition of the information element is
not permitted, only the contents of information element appearing first shall be handled and all
subsequent repetitions of the information element shall be ignored. When repetition of information
elements is permitted, only the contents of permitted information elements shall be handled. If thelimit on repetition of information elements is exceeded, the contents of information elements
appearing first up to the limit of repetitions shall be handled and all subsequent repetitions of theinformation element shall be ignored.
5.8.6 Mandatory information element errors
5.8.6.1 Mandatory information element missing
When a message other than SETUP, DISCONNECT, RELEASE or RELEASE COMPLETE is
received which has one or more mandatory information elements missing, no action should be takenon the message and no state change should occur. A STATUS message is then returned with cause
No. 96, mandatory information element is missing.
When a SETUP or RELEASE message is received which has one or more mandatory information
elements missing, a RELEASE COMPLETE message with cause No. 96, mandatory information
element is missing shall be returned.
When a DISCONNECT message is received with the cause information element missing, the actions
taken shall be the same as if a DISCONNECT message with cause No. 31, normal, unspecified was

90

B-IF2.02-02-TS

received (see 5.3), with the exception that the RELEASE message sent on the local interface contains
cause No. 96, mandatory information element is missing.
When a RELEASE COMPLETE message is received with a cause information element missing, it
will be assumed that a RELEASE COMPLETE message was received with cause No. 31, normal,
unspecified.
5.8.6.2 Mandatory information element content error
When a message other than SETUP, DISCONNECT, RELEASE, or RELEASE COMPLETE is
received which has one or more mandatory information elements with invalid content, no action
should be taken on the message and no state change should occur. A STATUS message is thenreturned with cause No. 100, “invalid information element contents”.
When a SETUP or RELEASE message is received which has one or more mandatory information
elements with invalid content, a RELEASE COMPLETE message with cause No. 100, “invalid
information element contents” shall be returned.
When a DISCONNECT message is received with invalid content of the Cause information element,
the actions shall be the same as if a DISCONNECT message with cause No. 31, “normal, unspecified”
was received (see 5.3), with the exception that the RELEASE message sent on the local interface
contains cause No. 100, “invalid information element contents”.
When a RELEASE COMPLETE message is received with invalid content of the Cause information
element, it will be assumed that a RELEASE COMPLETE message was received with cause No. 31,“normal, unspecified”.
Information elements with a length exceeding the maximum length (given in 3) shall be treated as an
information element with content error.
Note :As an option of the the Public CS , cause values, location codes, and diagnostics which are
not understood by the Public CS may be passed on to another entity instead of treating thecause value as if it were cause No. 31, normal, unspecified and sending cause No. 100,
invalid information element contents with the RELEASE message. This option is intended
to aid Public CS equipment to be compatible with future additions of cause values, location
codes and diagnostics to the Recommendation.

5.8.7 Non-mandatory information element errors
The following subclauses identify actions on information elements not recognized as mandatory.
5.8.7.1 Unrecognized information element
When a message is received which has one or more unrecognized information elements, the receiving
entity shall check whether any are encoded to indicate “comprehension required” (refer to Table 43/Q.931 for information element identifiers reserved with this meaning). If any unrecognized
information element is encoded to indicate “comprehension required” then the procedures in 5.8.6.1
are followed, i.e. as if a “missing mandatory information element” error condition had occurred. If all

B-IF2.02-02-TS

91

unrecognized information elements are not encoded to indicate “comprehension required”, then thereceiving entity shall proceed as follows:
Action shall be taken on the message and those information elements which are recognized and havevalid content. When the received message is other than DISCONNECT, RELEASE or RELEASECOMPLETE, a STATUS message may be returned containing one cause information element. The
STATUS message indicates the call state of the receiver after taking action on the message. The
Cause information element shall contain cause No. 99, “information element non-existent or not
implemented”, and the diagnostic field, if present, shall contain the information element identifier foreach information element which was unrecognized.
Subsequent actions are determined by the sender of the unrecognized information elements. If aclearing message contains one or more unrecognized information elements, the error is reported to the
local Public CS in the following manner:a) When a DISCONNECT message is received which has one or more unrecognized information
elements, a RELEASE message with cause No. 99, “information element non-existent or not
implemented”, shall be returned. The Cause information element diagnostic field, if present, shallcontain the information element identifier for each information element which was unrecognized.
b) When a RELEASE message is received which has one or more unrecognized information
elements, a RELEASE COMPLETE message with cause No. 99 “information element nonexistent or not implemented”, shall be returned. The Cause information element diagnostic field,
if present, shall contain the information element identifier for each information element which
was unrecognized.
c) When a RELEASE COMPLETE message is received which has one or more unrecognized
information elements, no action shall be taken on the unrecognized information.
Note :The diagnostic(s) of cause No. 99 facilitates the decision in selecting an appropriate
recovery procedure at the reception of a STATUS message. Therefore, it is recommended
to provide cause No. 99 with diagnostic(s) if a layer 3 entity expects the peer to take anappropriate action at the receipt of a STATUS message, although inclusion of diagnostic(s)is optional.

5.8.7.2 Non-mandatory information element content error
When a message is received which has one or more non-mandatory information elements with invalid
content, action shall be taken on the message and those information elements which are recognizedand have valid content. A STATUS message may be returned containing one Cause information
element. The STATUS message indicates the call state of the receiver after taking action on themessage. The Cause information element shall contain cause No. 100 “invalid information element
contents”, and the diagnostic field, if present, shall contain the information element identifier for each
information element which has invalid contents.
Information elements with a length exceeding the maximum length (given in 3) will be treated as an
information element with content error. But for access information elements (e.g. Public CS-Public
CS information element, Called party subaddress information element), cause No. 43, “access

92

B-IF2.02-02-TS

information discarded” is used instead of cause No. 100 “invalid information element contents”.
However, in some ISDNs, access information elements may be truncated and processed.
Note :As an option of the Public CS, cause values, location codes, and diagnostics which are notunderstood by the Public CS may be accepted, or in the case of Public CS, passed on toanother entity (e.g. PS) instead of ignoring the cause information element contents andoptionally sending a STATUS message with cause No. 100, invalid information element
contents. This option is intended to aid Public CS equipment to be compatible with future
additions of cause values, location codes and diagnostics to the Recommendation.

5.8.7.3 Unexpected recognized information element
When a message is received with a recognized information element that is not marked ascomprehension required and is not defined to be contained in that message, the receiving entity shall(except as noted below) treat the information element as an unrecognized information element andfollow the procedures defined in 5.8.7.1. When a message is received with a recognized information
element that is marked as comprehension required and is not defined to be contained in that message,
the receiving entity shall follow the procedures of 5.8.6.1.
Note :

Some implementations may chose to process unexpected recognized information elements
when the procedure for processing the information element is independent of the message
in which it is received.

5.8.8 Data link reset
Whenever a Q.931 entity is informed of a spontaneous data link layer reset by means of the DLESTABLISH indication primitive, the following procedures apply:a) For calls in the disestablishment phase (states N11, N12, N19, N22, C11, C12 and C19), no action
shall be taken.
b) Calls in the establishment phase (states N1, N3, N4, N6, N7, N8, N9, C1, C3, C4, C6, C7, C8
and C9) and in the Active, Suspend Request, and Resume Request states shall be maintained
according to the procedures contained in other parts of 5.
5.8.9 Data link failure
Whenever the ISDN layer entity is notified by its data link layer entity via the DL-RELEASE
indication primitive that there is a data link layer malfunction, the following procedure shall apply:a) Any calls not in the Active state shall be cleared internally.
b) For any call in the Active state a timer T309 shall be started (if implemented).
If timer T309 is already running, it shall not be restarted.
The Q.931 entity shall request layer 2 reestablishment by sending a DL-ESTABLISH request
primitive.
When informed of layer 2 re-establishment by means of the DL-ESTABLISH confirmation
primitive, the following procedure shall apply:

B-IF2.02-02-TS

93

the Q.931 entity shall stop timer T309, and either:-

the Q.931 entity shall send a STATUS message with cause No. 31, normal, unspecified toreport the current state to the peer entity; or-

the Q.931 entity shall perform the status enquiry procedure according to 5.8.10 to verify thecall state of the peer entity.

If timer T309 expires prior to data link reestablishment, the ISDN shall clear the ISDN connection
and call to the remote side with cause No. 27, destination out of order; disconnect and release theB-channel; release the call reference, and enter the Null state.
If timer T309 expires prior to data link reestablishment, the Public CS shall clear the attachedconnection (if any) with cause No. 27, destination out of order; disconnect and release the Bchannel; release the call reference, and enter the Null state.
The implementation of timer T309 in the Public CS side is optional and in the ISDN side is
mandatory.
When a Q.931 entity internally clears the call as a result of data link failure, as an option, it may
request the restablishment of the data link in order to attempt to send a DISCONNECT message
accross the interface.
5.8.10 Status enquiry procedure
Whenever an entity wishes to check the correctness of a call state at a peer entity, a STATUS
ENQUIRY message may be sent requesting the call state. This may, in particular, apply to procedural
error conditions described in 5.8.8 and 5.8.9.
Upon sending the STATUS ENQUIRY message, timer T322 shall be started in anticipation ofreceiving a STATUS message. While timer T322 is running, only one outstanding request for callstate information shall exist. Therefore, if timer T322 is already running, it shall not be restarted. If aclearing message is received before timer T322 expires, timer T322 shall be stopped, and call clearing
shall continue.
Upon receipt of a STATUS ENQUIRY message, the receiver shall respond with a STATUS message,
reporting the current call state (the current state of an active call or a call in progress, or the Null state
if the call reference does not relate to an active call or to a call in progress) and cause No. 30, response
to STATUS ENQUIRY or No. 97, message type non-existent or not implemented (see 5.8.4). Receipt of
the STATUS ENQUIRY message does not result in a state change.
The sending or receipt of the STATUS message in such a situation will not directly affect the call stateof either the sender or receiver. The side having received the STATUS message shall inspect the
Cause information element. If the STATUS message contains cause No. 97, message type non-existentor not implemented, timer T322 shall continue to time for an explicit response to the STATUS
ENQUIRY message. If a STATUS message is received that contains cause No. 30, response to status
enquiry, timer T322 shall be stopped and the appropriate action taken, based on the information in that94

B-IF2.02-02-TS

STATUS message, relative to the current state of the receiver. If timer T322 expires and a STATUS
message with cause No. 97, message type non-existent or not implemented was received, theappropriate action shall be taken, based on the information in that STATUS message, relative to thecurrent call state of the receiver.
These further appropriate actions are implementation dependent. However, the actions prescribed in
the following subclause shall apply.
If timer T322 expires, and no STATUS message was received, the STATUS ENQUIRY message may
be retransmitted one or more times until a response is received. The number of times the STATUS
ENQUIRY message is retransmitted as an implementation dependent value. The call shall be cleared
to the local interface with cause No. 41, temporary failure, if the STATUS ENQUIRY is retransmitted
the maximum number of times. If appropriate, the ISDN shall also clear the ISDN connection, using
cause No. 41, temporary failure.
5.8.11 Receiving a STATUS message
On receipt of a STATUS message reporting an incompatible state, the receiving entity shalla) clear the call by sending the appropriate clearing message with cause No. 101, message notcompatible with call state; orb) take other actions which attempt to cover from a mismatch and which are an implementation
option.
Except for the following rules, the determination of which states are incompatible is left as animplementation decision:a) If a STATUS message indicating any call state except the Null state is received in the Null state,then the receiving entity shall either
1) send a RELEASE message with cause No. 101, message not compatible with call state, andthen follow the procedures of 5.3; or
2) send a RELEASE COMPLETE message with cause No. 101, message not compatible withcall state; and remain in the Null state.
b) If a STATUS message indicating any call state except the Null state is received in the release
request state, no action shall be taken.
c) If a STATUS message, indicating the Null state, is received in any state except the Null state, thereceiver shall release all resources and move into the Null state.
When in the Null state, the receiver of a STATUS message indicating the Null state shall take noaction other than to discard the message and shall remain in the Null state.
A STATUS message may be received indicating a compatible call state but containing one of thefollowing causes:

B-IF2.02-02-TS95i) No. 96 - Mandatory information element is missing;ii) No. 97 - Message type non-existing or not implemented;iii) No. 99 - Information element non-existent or not implemented; oriv) No. 100 - Invalid information element contents.
In this case the actions to be taken are an implementation option. If other procedures are not defined,
the receiver shall clear the call with the appropriate procedure defined in 5.3, using the cause specified
in the received STATUS message.
On receipt of a STATUS message specifying the global call reference and reporting an incompatible
state in the restart request or restart state, the receiving Q.931 entity shall inform layer management
and take no further action on this message.
When in the Null state, then on receipt of a STATUS message with the global call reference no action
shall be taken.
Note :

Further actions as a result of higher layer activity (e.g. system or layer management) and
implementation dependent (including the retransmission of RESTART).

Except for the above case, the error handling procedures when receiving a STATUS message
specifying the global call reference are an implementation option.
5.9 Public CS notification procedure
This procedure allows the ISDN to notify a Public CS of any appropriate call-related event during theactive state of a call by sending a NOTIFY message containing a notify indicator to the ISDN; uponreceipt of this message, the ISDN must send a NOTIFY message containing the same notify indicator
to the other Public CS involved in the call. No state change occurs at any of the interface sides
following the sending or the receipt of this message.
5.10 Basic telecommunication service identification and selection *†}5.11 Signalling procedures for bearer capability selection *†}5.12 Signalling procedures for high layer compatibility selection *†}6. Packet communication procedures *7. User signalling bearer service call control procedures *8. Circuit-mode multirate (64 kbit/s base rate) procedures *96

B-IF2.02-02-TS

9. List of system parameters
The description of timers in the following tables should be considered a brief summary. The precise
details are found in clause 5, which should be considered the definitive descriptions.
9.1 Timers in the ISDN side
The timers specified in Table 9-1 are maintained in the ISDN side of the interface.
9.2 Timers in the Public CS side
The timers specified in Table 9-2 are maintained in the Public CS side of the interface. Timers T305,
T308 and T313 are mandatory for all Public CS side implementations.

B-IF2.02-02-TS

97

98
B-IF2.02-02-TS

Table 9-1/ B-IF2.02(Q.931)
Timers in the ISDN side
Timer
number
T301

Defaut time-out
value
Minimum 3 min

T303

T305

State of call

Cause for start

Call received

ALERT received

4~5 s(Note 1)

Call present

SETUP sent

30 s

Disconnect
indication

DISC without
progress
indicator No. 8
sent

Normal stop
CONNECT
received
CALL PROC
received

REL or DISC
received

At the first expiry

At the second
expiryClear call
Retransmit
SETUP; restartT303. If REL
COMPLETE has
been received,
clear the call
ISDN sends REL

Cross-reference(Note 2)

Clear ISDN
connection. Entercall abort state

Mandatory

Timer is notrestarted

Mandatory

Table 9-1/ B-IF2.02(Q.931) (continued)
Timers in the ISDN side
Timer
number
T306

Defaut time-out
value
30 s
(Note 5)

T308

State of call

Cause for start

Normal stop

At the first expiry

Disconnect
indication

DISC with
progress indicator
No. 8 sent

REL or DISC
received

Stop thetone/announceme
nt. Send REL

4s(Note 1)

Release request

REL sent

REL COMPLETE
or REL received

Retransmit REL
and restart T308

T309

90 s

Any stable state

Data link
disconnection.
Calls in stablestates are not lost

Data linkreconnected

T310

10 s
(Note 7)

Incoming Call
Proceeding

CALL PROC
received

ALERT,
CONNECT or
DISC received. If
DISC, retain cause
and continue
timingClear ISDN
connection.
Release Bchannel and callreference
Clear call inaccordance with
5.2.5.3

At the second
expiryTimer is notrestarted

Place B-channel
in maintenancecondition Releasecall reference(Note 6)
Timer is notrestarted

Timer is notrestarted

Cross-reference
Mandatory when
inbandtones/announcements areprovided; see 5.4,
5.3.4.1, andRec. I.300-Series
Mandatory

Mandatory

Mandatory

B-IF2.02-02-TS
99

100
B-IF2.02-02-TS

Table 9-1/ B-IF2.02(Q.931) (continued)
Timers in the ISDN side
Timer
number
T312

Defaut time-out
value
T303 + 2 s

State of call

Cause for start

T314

4s

T316

T317

Normal stop

At the first expiry

SETUP sent or
resentMessage segment
received

Timeout(Note 4)

Last message
segment received

Discard message

2 minCall Present, Call
Abort, etc.
Receivingsegmented
message
Restart request

RESTART sent

RESTART ACK
received(Note 3)

RestartRESTART
received

Internal clearing ofcall references

RESTART may
be retransmitted
several times
Maintenancenotification

At the second
expiryTimer is notrestarted
Timer is notrestarted
RESTART may
be retransmitted
several times
Timer is notrestarted

Cross-reference
Mandatory
Mandatory see
Annex H
Mandatory when
5.5 isimplemented
Mandatory when
5.5 isimplemented

Table 9-1/ B-IF2.02(Q.931) (end)Timers in the ISDN side
Timer
number
T322

Defaut time-out
value
4s

State of call
Any all state

Cause for start
STATUS ENQ sent

Normal stop

At the first expiry

STATUS DISCREL or REL
COMPLETE
received

STATUS ENQ may
be retransmitted
several times

At the second
expirySTATUS ENQ may
be retransmitted
several times

Cross-reference
Mandatory when
5.8.10 is
implemented

Note 1: This default value assumes the use of default values at layer 2 (i.e. N200 + 1] times T200). Whether these values should be modified when layer 2 default values are
modified by an automatic negotiation procedure is for further study.
Note 2: The ISDN may already have applied an internal alerting supervision timing function; e.g. incorporated within call control. If such a function is known to be
operating on the call, then timer T301 is not used.
Note 3: The value of this timer is implementation dependent but should be less than the value of T316.
Note 4: If in the call abort state, the call reference is released. Otherwise, no action is taken on expiry of timer T312.
Note 5: The value of timer T306 may depend on the length of the announcement.
Note 6: The restart procedures contained in 5.5 may be used on B-channels in the maintenance condition.

B-IF2.02-02-TS
101

102
B-IF2.02-02-TS

Table 9-2/ B-IF2.02(Q.931)
Timers in the Public CS side
Timer
number
T301

Defaut time-out
value
Minimum 3 min.

State of call

Cause for start

Normal stop

Call Delivered

ALERT received

4s(Note 1)

Call Initiated

SETUP sent

CONNECT
received
CALL PROC or
REL COMPLETE
received

T303

T305

30 s

Disconnect
RequestDISC sent

REL or DISC
received

At the first expiry
Clear call
Retransmit
SETUP; restartT303. If REL
COMPLETE wasreceived, clear thecall
REL sent

At the second
expiryTimer is notrestarted
Clear internal
connection. Send
REL
COMPLETE.
Enter Null state

Cross-reference

Timer is notrestarted

Mandatory

Table 9-2/ B-IF2.02(Q.931) (continued)
Timers in the Public CS side
Timer
number
T308

Defaut time-out
value
4s(Note 1)

T309

State of call

Cause for start

Normal stop

At the first expiry

B-IF2.02-02-TS

Release request

REL sent

REL COMPLETE
or REL received

Retransmit REL;
and restart T308.

90 s

Any stable state

Data link
disconnection.
Calls in stablestates are not lost

Data linkreconnected

T310(Note 4)30-120 s

Outgoing Call
Proceeding

CALL PROC
received

T313

Connect request

CONNECT sent

T314

4s
(Note 1)
4s

Message segment
received

T316

2 min

Receiving
Segmented
Message
Restart Request

ALERT,
CONNECT, DISC,
or PROGRESS
received
CONNECT ACK
received
Last message
segment received

Clear internal
connection.
Release Bchannel and callreference
Send DISC

T317(Note 2)

RestartRESTART sent

RESTART ACK
received

RESTART
received

Internal clearing ofcall reference

Send DISC
Discard message

RESTART may
be retransmitted
several times
Maintenancenotification

At the second
expiryB-channel isplaced inmaintenancecondition. Callreference released(Note 5)Timer is notrestarted

Cross-reference
Mandatory

Optional

Timer is notrestarted

Timer is notrestarted
Timer is notrestarted

MandatoryRESTART may
be retransmitted
several times
Timer is notrestarted

Mandatory when
5.5 isimplemented
Mandatory when
5.5 isimplemented

Refer to Annex H
Mandatory

103

104
B-IF2.02-02-TS

Table 9-2/B-IF2.02(Q.931) (end)Timers in the Public CS side
Timer
number
T322

Defaut time-out
value
4s

State of call

Cause for start

Normal stop

At the first expiry

Any call state

STATUS ENQ
sent

STATUS, DISC,REL, RELCOMPLETE
received

STATUS ENQ
may beretransmitted
several times

At the second
expirySTATUS ENQ
may beretransmitted
several times

Cross-reference
Mandatory when
5.8.10 is
implemented

Note 1: This default value assumes the use of default values at layer 2, i.e. [N200 + 1] times T200. Whether these values should be modified when layer 2 default
values are odified by an automatic negotiation procedure is for further study.
Note 2: The value of this timer is implementation dependent, but should be less than the value of T316.
Note 3: The Public CS may already have applied an internal alerting supervision timing function, e.g. incorporated within call control. If such a function is known
to be operating on the call, then timer T301 is not used.
Note 4: T310 is not started if progress indicator 1 or 2 has been delivered in the CALL PROCEEDING message or in a previous PROGRESS message.
Note 5: The restart procedures contained in 5.5 may be used on B-channels in the maintenance conditions.

Annex A

Public CS side and ISDN side SDL diagrams(This annex forms an integral part of this specification)
This annex includes overview and detailed SDL diagrams which show Q.931 protocol control for
circuits-switched basic calls. In the event of conflict berween these diagrams and the text of clause 5,
the text should be the prime source. Similarly, in the event of conflict between overview SDL anddetailed SDL diagrams, the detailed SDL diagrams should be the prime source.
Figure A.1 shows key to Q.931 protocol control SDL diagrams for both public cell station side and
ISDN side.
Figures A.2 and A.3 show overview and detailed protocol control SDL diagrams for the public cellstation side.
Figures A.5 and A.6 show overview and detailed protocol control SDL diagrams for ISDN side.
Figure A.4 shows detailed SDL diagrams for the global call reference to be applied to both public cellstation and ISDN sides. Although Figure A.4 shows SDL diagrams in the public cell station-side only,
the same diagrams can be applied to the ISDN side by just changing the direction of input and output
symbols.

B-IF2.02-01-TS

105

*

Call Control(Primitives)

Resource
Management(Procedure Call)

Block described by
the SDL diagrams

Q.931 Protocol Control(Message to/from
ISDN Side)

Data Link Layer
Physical Layer
Public CS ISDN Interface(ISDN): State: Primitive from call control: Primitive to call control: Message from ISDN side
: Message to ISDN side
: Procedure call
: Decision: Alternate: Save: Process description (Task)*: Not described in the SDL diagrams

Figure A.1 / B-IF2.02(Q.931) (1/2)
Key to Q.931 protocol control SDL diagrams (Public CS side)106

B-IF2.02-01-TS*Call Control(Primitives)

Resource
Management(Procedure Call)

Block described by
the SDL diagrams

Q.931 Protocol Control(Message to/from Public CS)

Data Link Layer
Physical Layer
Public CSISDN Interface(Public CS): State: Primitive from call control: Primitive to call control: Message from Public CS side
: Message to Public CS side
: Procedure call
: Decision: Alternate: Save: Process description (Task)*: Not described in the SDL diagrams

Figure A.1 / B-IF2.02 (Q.931) (2/2)
Key to Q.931 protocol control SDL diagrams (ISDN side)

B-IF2.02-01-TS

107

0
NULL

SETUP REQUEST

SETUP

1
CALL INIT

CALL PROCEEDING

PROC INDICATION3OUTGOING CALLPROCEEDINGa) Outgoing set-up procedure (1/2)
Figure A.2 / B-IF2.02 (Q.931) (1/8)
Overview protocol control (public CS side)108

B-IF2.02-01-TS

3
OUTGOING CALLPROCEEDING

ALERTING

CONNECT

ALERTING
INDICATION

4CALL
DELIVEREDCONNECT

SETUP CONFIRMACK OPTIONCONNECT ACK

10ACTIVEa) Outgoing set-up procedure (2/2)
Figure A.2 / B-IF2.02 (Q.931) (2/8)
Overview protocol control (public CS side)

B-IF2.02-01-TS

109

0
NULL

SETUP

SETUP
INDICATION

6CALL PRESENTREJECT
REQUESTPROCEEDINGREQUESTCALL
PROCEEDINGREJECT OPTION
9INCOMING CALLPROCEEDINGRELEASECOMPLETE

ALERTING
REQUESTSETUPRESPONSE

ALERTING

CONNECT

7
CALL RECEIVED

0
NULL

8
CONNECTREQUESTb) Incoming set-up procedure (1/2)
Figure A.2 / B-IF2.02 (Q.931) (3/8)
Overview protocol control (public CS side)110

B-IF2.02-01-TS

7
CALL RECEIVEDSETUP RESPONSE

CONNECT

8

CONNECTREQUEST

CONNECT ACKSETUP COMPLETE
INDICATION10ACTIVEb) Incoming set-up procedure (2/2)
Figure A.2 / B-IF2.02 (Q.931) (4/8)
Overview protocol control (public CS side)

B-IF2.02-01-TS

111c) Overlap receiving procedure
Figure A.2 / B-IF2.02 (Q.931) (5/8)
Overview protocol control (public CS side)112

B-IF2.02-01-TS**
ANY STATEEXCEPT 0, 1, 6, 11, 1
2, 19

DISCONNECT

RELEASEDISCONNECT
REQUESTDISCONNECT
INDICATIONRELEASEINDICATIONDISCONNECT

12
DISCONNECT
INDICATIONRELEASECOMPLETE

11
DISCONNECT
REQUESTRELEASEREQUESTRELEASERELEASEDISCONNECT

RELEASERELEASEINDICATIONRELEASEINDICATIONRELEASERELEASECOMPLETE

RELEASECOMPLETE

19
RELEASE REQUESTRELEASECOMPLETE0NULL

RELEASECONFIRMd) Clearing procedure
Figure A.2 / B-IF2.02 (Q.931) (6/8)
Overview protocol control (public CS side)

B-IF2.02-01-TS

113

10
ACTIVENOTIFYNOTIFYINDICATION10ACTIVEe) Suspend procedure
Figure A.2 / B-IF2.02 (Q.931) (7/8)
Overview protocol control (public CS side)114

B-IF2.02-01-TS

f) Resume procedure
Figure A.2 / B-IF2.02 (Q.931) (8/8)
Overview protocol control (public CS side)

B-IF2.02-01-TS

115

116

B-IF2.02-01-TS
Note4
Note5

1
CALL INITIATED

START T303

SETUP (Bu CHAN)

CALL REFERENCE
SELECTION

SETUP REQUEST(Bc CHAN)

5.1.1

Note3

Note5

0

5.8.11NULL

STATUS(CS=0)

NULL

Detailed protocol contro l (public CS side)

Figure A.3 / B-IF2.02 (Q.931) (1/24)

In the event of conflict between these diagrams and the text of clause 5, the text should be the prime source.
These diagrams show Q.931 protocol control for circuit-switched calls.
T303 and T318 are optional(see 9.2)
"Bn chan" is a B-channel selected by the network.
"Bc chan" is a B-channel selected by the public CS.

CALL PRESENT

Note 1:
Note 2:
Note 3:Note 4:Note 5:6

SETUP
INDICATIONSETUP (Bn CHAN)

5.2.1

0

19
RELEASE REQUESTSTART T308

RELEASE(CAUSE#101)

0

REL OPTIONSTATUS(CS°0)

5.8.11NULL

RELEASECOMPLETE(CAUSE#101)

B-IF2.02-01-TS

117

UNRECOGNIZEDMESSAGE

5.8.3.2a)19
RELEASE REQUESTSTART T308

RELEASE(CAUSE#81)

NULL

0
NULL

NULL

RELEASECOMPLETE

0RELEASECOMPLETE

5.8.3.2c)

RELEASE

5.8.3.2b)•••Continued

Figure A.3 / B-IF2.02 (Q.931) (2/24)

0

RELEASECOMPLETE(CAUSE#81)

NULL

Detailed protocol control (public CS side)

REL OPTIONUNEXPECTEDMESSAGE

5.8.3.2d)0118

B-IF2.02-01-TS
CALL
INITIATED

Detailed protocol control (public CS side)

Figure A.3 / B-IF2.02 (Q.931) (3/24)

1

3
OUTGOING CALLPROCEEDING

START T305

NULL

PROCEEDING
INDICATIONRELEASECALL REFERENCE

STOP T303

0

START T303

START T310

REJECT
INDICATIONDISCONNECTDISCONNECT
REQUEST

SETUP (Bn CHAN)

STOP T303

STOP T303

Note 1: T303,T310 are optional(see 9.2)
Note 2: "B chan" is a B-channel negotiated by the digital network and the public CS

11

FIRST
TIMEOUTCALL PROCEEDING(B chan)

RELEASECOMPLETEDISCONNECT
REQUESTY

T303 TIMEOUT

5.1.5.1

5.1.1 5.1.2
5.3.2

CALL
INITIATED

5.3.3

1

N

0
NULL

RELEASECALL REFERENCE

SETUP CONFIRM(ERROR)B-IF2.02-01-TS

119

Detailed protocol control (public CS side)

Figure A.3 / B-IF2.02 (Q.931) (4/24)

120

B-IF2.02-01-TS
Detailed protocol control (public CS side)

Figure A.3 / B-IF2.02 (Q.931) (5/24)

B-IF2.02-01-TS

121

4

Note :

T310 is optional(See 9.2)

CALL
DELIVEREDALERTING
INDICATIONPROGRESSINDICATIONDISCONNECT
REQUEST

Figure A.3/B-IF2.02 (Q.931) (6/24)

ACTIVE

11

SETUP CONFIRM(ERROR)

START T305

DISCONNECT

T310 TIMEOUT

Detailed protocol control (public CS side)

10

CONNECT ACKACK OPTIONSETUP CONFIRMSTOP T310

STOP T310

STOP T310

5.1.8

CONNECT

5.1.7

ALERTINGOUTGOING CALLPROCEEDING

3

5.1.6

PROGRESS

5.4

3
OUTGOING CALLPROCEEDING

19
RELEASEREQUEST

START T308

RELEASE(CAUSE#6)

STOP T310

RELEASEREQUEST

5.3.2dCONNECT

5.1.8

CALL
DELIVERED10
ACTIVECONNECT ACKACK OPTIONSETUP CONFIRM

4

122

B-IF2.02-01-TS

0

NULL

RELEASE CALLREFERENCERELEASE COMPLATE(CAUSE)*INCOMING
CALL PROCEEDING

9

CALL PROCEEDING(B chan)

Note

PROCEEDINGREQUEST(B chan)

5.2.5.1

CALL PRESENT

5.3.2

Detailed protocol control (public CS side)

NULL

RELEASE CALLREFERENCERELEASECOMPLATE

RELEASEINDICATIONRELEASE(CAUSE)

0

Figure A.3 / B-IF2.02 (Q.931) (7/24)

Note : "B chan" is a B-channel negotiated by the digital network and the public CS

REJECT OPTION
also see 5.2.5.1

REJECT
REQUEST

5.2.5.1
5.2.3
5.2.2

6

12
DISCONNECT
INDICATIONDISCONNECT
INDICATIONDISCONNECT(CAUSE)

5.3.4

B-IF2.02-01-TS

123

8

CONNECTREQUEST

8

11
DISCONNECT
REQUEST

SETUP COMPLETE
INDICATION(ERROR)

ACTIVECONNECTREQUEST

Detailed protocol control (public CS side)

Figure A.3 / B-IF2.02 (Q.931) (8/24)

10

START T313

SETUP COMPLETE
INDICATIONSTART T305

START T313

CONNECT

STOP T313

CONNECTDISCONNECT

5.2.7
5.2.5.1

SETUP
RESPONSE

5.2.8

CONNECTACKNOWLEDGE

5.2.8

CONNECTREQUEST

TIMEOUT T313

8

SETUP
RESPONSE

5.2.7
5.2..5.1

7
CALL RECEIVED

PROGRESS9INCOMING CALLPROCEEDING

7
CALL RECEIVED

PROGRESSREQUEST

5.2.6

ALERTING

ALERTING
REQUEST

5.2.5.1

9
INCOMING CALLPROCEEDING

B-IF2.02-01-TS
ACTIVE

Detailed protocol control(public CS side)

Figure A.3/B-IF2.02(Q.931)(9/24)

10

NOTIFYINDICATIONNOTIFY

5.9
5.6.4
5.6.2

ACTIVE

10124

B-IF2.02-01-TS

125

Note

0
NULL

RELEASE CALLREFERENCERELEASECOMPLETE

19

Detailed protocol control (public CS side)

Note : After receiving this primitive,
call control process should release B-channel

RELEASEREQUEST

START T308

RELEASE(CAUSE)TIMEOUT T305

5.3.3

Figure A.3 / B-IF2.02 (Q.931) (10/24)

19
RELEASEREQUEST

START T305

RELEASESTOP T305

STOP T305

RELEASEINDICATIONDISCONNECT(CAUSE)

5.3.5

RELEASE

5.3.3

11
DISCONNECT
REQUEST

126

B-IF2.02-01-TS
0
NULL

19
RELEASEREQUEST

START T308

RELEASE

Figure A.3 / B-IF2.02 (Q.931) (11/24)

Note

RELEASEREQUEST

5.3.4

Detailed protocol control (public CS side)

RELEASE CALLREFERENCERELEASECOMPLETE

RELEASEINDICATIONRELEASE

5.8.4

12
DISCONNECT
INDICATION

Note : After receiving this primitive,
call control process should release B-channel

B-IF2.02-01-TS

127

Detailed protocol control (public CS side)

Figure A.3 / B-IF2.02 (Q.931) (12/24)

128

B-IF2.02-01-TS
Detailed protocol control (public CS side)

Figure A.3 / B-IF2.02 (Q.931) (13/24)

B-IF2.02-01-TS

129

0

0

Note : After receiving this primitive,
call control process should release B-channel

NULL

RELEASE CALLREFERENCERELEASE CALLREFERENCENULL

RELEASECONFIRM

Note

STOP T308

STOP T308

RELEASECONFIRM

Note

RELEASE

5.3.5

RELEASECOMPLATE

5.3.4

RELEASEREQUESTN0
NULL

RELEASE CALLREFERENCERELEASECONFIRM(ERROR)

PLACE B-CHANNELIN MAINTENANCE(USER'S OPTION)

Detailed protocol control (public CS side)

Figure A.3 / B-IF2.02 (Q.931) (14/24)

19

RESTART T308

RELEASEYFIRST TIMEOUTTIMEOUT T308

5.3.4

19
RELEASE REQUEST19
RELEASEREQUESTSTATUS (CS°0)

5.8.110
NULL

RELEASE CALLREFERENCESTATUS
INDICATION(ERROR)STATUS (CS–0)

5.8.11

130

B-IF2.02-01-TS
Detailed protocol control (public CS side)

Figure A.3 / B-IF2.02 (Q.931) (15/24)

B-IF2.02-01-TS

131

Note

Y

11
DISCONNECT
REQUEST

START T305

DISCONNECT(CAUSE)STATUS(ERROR)
INDICATIONNCOMPATIBLE
STATE

m=0

STATUS(CS=m)

5.8.11ANY STATEEXCEPT 0.19

Y

Detailed protocol control (public CS side)

Figure A.3/B-IF2.02 (Q.931) (16/24)

Note : Action on receipt of STATUS indicating a compatible
call state is implementation dependent(see 5.8.11)

REMAIN IN
CURRENTSTATESTATUSSTATUSENQUIRY

5.8.10ANY STATE0NULL

RELEASE CALLREFERENCESTATUS
INDICATION

132

B-IF2.02-01-TS
Detailed protocol control(public CS side)

Figure A.3/B-IF2.02(Q.931)(17/24)

B-IF2.02-01-TS

133

NULL
0

NULL

RELEASECALL
REFERENCERELEASECOMPLATE

RELEASEINDICATIONSTOPALL TIMERS

RELEASE(CAUSE)

5.8.4

12
DISCONNECT
INDICATIONDISCONNECT
INDICATIONSTOPALL TIMERSDISCONNECT(CAUSE)

5.3.4**ANY STATE
EXCEPT 0.1.6.11.12.19

Detailed protocol control (public CS side)

Figure A.3 / B-IF2.02 (Q.931) (18/24)

Note

Note : After receiving this primitive,call control should release B-channel

0

RELEASEINDICATIONSTOPALL TIMERS

RELEASECOMPLATE

RELEASE CALLREFERENCE

5.8.4**ANY STATE
EXCEPT 0.1.19

11
DISCONNECT
REQUEST

START T305

DISCONNECT(CAUSE)DISCONNECT
REQUEST

5.3.3

134

B-IF2.02-01-TS
REMAIN IN
CURRENT STATEREMAIN IN
CURRENT STATEREMAIN IN
CURRENT STATERELEASECOMPLATE

REMAIN IN
CURRENT STATESTATUS(CAUSE#97)

CAUSE
OPTIONSTATUS ENQ.
OPTION

Note

UNREEXPECTEDMESSAGE

5.8.4

Detailed protocol control (public CS side)

Figure A.3 / B-IF2.02 (Q.931) (19/24)

STATUS(CAUSE#98)

STATUS(CAUSE#101)

CAUSE
OPTION

Note : Except RELEASE or RELEASE COMPLATEREMAIN IN
CURRENT STATERELEASECOMPLATESTATUS ENQ.
OPTIONNote

UNEXPECTEDMESSAGE

5.8.4**ANY STATE
EXCEPT 0

REMAIN IN
CURRENT STATESTATUS(CAUSE#98)

REMAIN IN
CURRENT STATE

SETUP

5.8.3.2(e)B-IF2.02-01-TS

135

NULL

NULL

SPECIFIC
STATE

Detailed protocol control (public CS side)

0

RELEASEINDICATION

12DISCONNECT
INDICATIONREMAIN IN
CURRENT
STATE

NULL

RELEASECR

RELEASECOMPLETE(CAUSE#100)

RELEASE
WITH
CAUSE I.E
ERROR

5.8.6.2

DISC
INDICATIONDISCONNECT
WITH
CAUSE I.E
ERROR

5.8.6.2

Note 2
Note 3STATUSCOMPLETE(CAUSE#96)

MESSAGE W/OMANDATORY
I.E

Note‚P

5.8.6.1**

Figure A.3 / B-IF2.02 (Q.931 )(20/24)

0

RELEASE CR

Note 1: Except SETUP, RELEASE RELEASE COMPLETE and DISCONNECT.
Note 2: These messages are recognized by the public CS and expected messages inthe state. [see Figure A.3(Sheet 15 of 25)]
Note 3: See 5.8.6 procedures for specific states.

NULL

RELEASEINDICATION

12DISCONNECT
INDICATION

NULL

0

0

RELEASECOMPLETE(CAUSE#96)

DISC
INDICATIONRELEASECOMPLETE(CAUSE#100)

RELEASE
W/O
CAUSE I.E

5.8.6.1

RELEASECOMPLETE(CAUSE#96)

DISCONNECT
W/O
CAUSE I.E

5.8.6.1

SETUP
WITH
MANDATORY
I.E ERROR

5.8.6.2

SETUP W/O
MANDATORY
I.E

5.8.6.1

0

REMAIN IN
CURRENTSTATESTATUS(CAUSE#100)

MESSAGE W/OMANDATORY
I.E ERROR

Note‚P

5.8.6.2

136

B-IF2.02-01-TS
NULL

Figure A.3/B-IF2.02(Q.931)(21/24)

0

RESTART CONFIRMRELEASE CALLREFERENCERELEASEINDICATIONSTOP ALL TIMERSRESTART REQUEST

5.5.2

Any State

Detailed protocol control(public CS side)

To global callreference control

From global callreference control**

B-IF2.02-01-TS

137

Detailed protocol control(public CS side)

Figure A.3/B-IF2.02(Q.931)(22/24)

REMAIN IN
CURRENT STATEDL-ESTABLISH-INDICATION

5.8.8

RELEVANTSTATES

138

B-IF2.02-01-TS

Note 1: Any timers including T309
Note 2: T309 is optional (see 9.2)

0

0

NULL

DL-RELEASE-INDICATION

NULL

NULL

Detailed protocol control(public CS side)

Figure A.3/B-IF2.02(Q.931)(23/24)

0

RELEASE CALLREFERENCESTOPALL TIMERSDL-RELEASE-INDICATION

5.8.9

Any state**
exept 0

REMAIN IN
CURRENT STATEDL-ESTABLISH-REQUESTSTART T309

N

TIMER RUNNING ?

Note 1Y

B-IF2.02-01-TS

139

Note:

T309 is optional (see 9.2)

STATUSENQUIRY

T309

Detailed protocol control(public CS side)

Figure A.3/B-IF2.02(Q.931)(24/24)

REMAIN IN
CURRENT STATESTATUS

STOP

T309

0
NULL

RELEASE CALLREFERENCEDATA LINKFAILURE INDICATIONTIMEOUT

DL-ESTABLISH-CONFIRM

STATE

5.8.9

ANY

5.8.9

**

140

B-IF2.02-01-TS
REST 0REST 0START T316

RESTART

N=0

MANAGEMENTRESTART REQUEST

5.5.1

Figure A.4/B-IF2.02(Q.931)(1/4)

REST 2

START T317(FS)

To Q.931
protocolcontrol(related callreference)

From systemmanagement

REST 0REST 1

START T317

RESTART
REQUEST

Detailed protocol control for the global call reference(public CS side)

Note 1: T316 and T317 are optional (see 9.2)
Note 2: The value of T317 is implementation dependent

TRANSLATEINTOINDIVIDUALCALL
REFERENCERESTART
REQUESTRESTART(CS=0)

5.5.2(CS=0)All timers stopped

All flags (e.g. "Rest ack", "Rest resp") cleared

GLOBAL CALL REFERENCE

Note 2

To Q.931
protocolcontrol(specified callreference)

REST 0STATUS(CAUSE #81)

UNEXPECTEDMESSAGE

5.8.3.2 (5)B-IF2.02-01-TS

141

REST 1STATUS

MAINTENANCE
ACTION

Y

N=2 ?

N=N+1

TIMEOUT

T316

5.5.1

N

REST 1STATUS (CAUSE #81)

UNEXPECTEDMESSAGE

5.8.3.2 (f)Detailed protocol control for the global call reference(public CS side)

Figure A.4/B-IF2.02(Q.931)(2/4)

REST 1REST 0START T316

REST 1REST ACK ONNREST RESP OFFYREST RESP ON

STOP

T316

RESTART ACK

5.5.1

RESTARTRESTART REQUEST(GLOBAL CALL REFERENCE)

142

B-IF2.02-01-TS
REST 0REST ACK OFF

Y

REST ACK ON?

STOP T317

Y

ALL RESPONSE?

N

Continued

RESTART
CONFIRM

Detailed protocol control for the global call reference(public CS side)

Figure A.4/B-IF2.02(Q.931)(3/4)

Note: T317 is optional (see 9.2)

MAINTENANCE
ACTIONTIMEOUT

T317

RESTART REQUEST(GLOBAL CALL REFERENCE)N

REST 1REST RESP ON

From Q.931 protocoll control(each call reference)

REST 1

B-IF2.02-01-TS

143

TIMEOUT

T317

N

Figure A.4/B-IF2.02(Q.931)(4/4)

REST 0RESTART ACKSTOP T317

Y

ALL RESPONSE?

RESTART
CONFIRM

5.5.2

REST 2

From Q.931 protocol control(each call reference)

Detailed protocol control for the global call reference(public CS side)

MAINTENANCE
ACTION

Note: T317 is optional (see 9.2)

REST 2STATUS

5.5.2

RESTART

GLOBAL CALL REFERENCEREST 2STATUS (CAUSE #81)

UNEXPECTEDMESSAGE

5.8.3.2(f)

0
NULL

SETUP

SETUP
INDICATION

5.1.1
1
CALL INIT

5.3.2.a
5.1.6

REJECT
REQUEST

PROC REQUESTCALLPROCEEDINGRELEASECOMPLETE

3
OUTGOING CALLPROCEEDING0
NULLa) Outgoing set-up procedure(1/2)
Figure A.5/B-IF2.02(Q.931)(1/9)
Overview protocol control (ISDN side)144

B-IF2.02-01-TS

3
OUTGOING CALLPROCEEDING

5.1.6

SETUP
RESPONSE

PROGRESSREQUEST

5.1.7

ALERTING
REQUESTPROGRESSALERTING

3
OUTGOING CALLPROCEEDING

4
CALL DELIVEREDSETUPRESPONSE

CONNECT10ACTIVEa) Outgoing set-up procedure(2/2)
Figure A.5/B-IF2.02(Q.931)(2/9)
Overview protocol control (ISDN side)

B-IF2.02-01-TS

145

0
NULL

5.2.1
SETUP
REQUEST

SETUP

6CALL PRESENT

5.2.2
RELEASECOMPLETEREJECT
INDICATION

0
NULL

5.2.5.2
CALL
PROCEEDINGPROC
INDICATION9INCOMING CALLPROCEEDINGb) Incoming set-up procedure(1/3)
Figure A.5/B-IF2.02(Q.931)(3/9)
Overview protocol control (ISDN side)146

B-IF2.02-01-TS

9
INCOMING CALLPROCEEDING

5.2.5.2

5.2.7

5.2.6

ALERTING

CONNECT

PROGRESSSETUPCONFIRM

ALERTING IND

7CALL RECEIVED

8
CONNECTREQUESTPROGRESS IND

9
INCOMING CALLPROCEEDINGb) Incoming set-up procedure(2/3)
Figure A.5/B-IF2.02(Q.931)(4/9)
Overview protocol control (ISDN side)

B-IF2.02-01-TS

147

7
CALL RECEIVED

CONNECTSETUP
CONFIRM

88
CONNECTREQUESTSETUP
COMPREQUEST

CONNECT ACK

10CONNECTREQUEST

ACTIVEb) Incoming set-up procedure(3/3)
Figure A.5/B-IF2.02(Q.931)(5/9)
Overview protocol control (ISDN side)148

B-IF2.02-01-TS

ANY STATE
EXCEPT0, 11, 12, 19, 22
5.3.3

5.3.4

DISCONNECT
REQUESTDISCONNECTDISCONNECT
B-CHANTONEMANAGEMENT

Note 1DISCONNECT
IND

DISCONNECT
B-CHAN

Note 2

11
DISCONNECT
REQUESTDISCONNECT

12
DISCONNECT
INDICATION

Note1: Optional (for inband tones)
Note2: Dependent on tone managementc) Clearing procedure(1/2)
Figure A.5/B-IF2.02(Q.931)(6/9)
Overview protocol control (ISDN side)

B-IF2.02-01-TS

149

11

12
DISCONNECT
REQUESTDISCONNECT
INDICATION

5.2.5.2

5.2.6

DISCONNECT

RELEASERELEASEREQUESTRELEASERELEASE
B=CHAN

19
RELEASEREQUESTRELEASE INDRELEASECOMPLETE

RELEASECOMPLETE

RELEASE CR

RELEASE
B-CHAN & CR0
NULL

RELEASE CONF

0
NULLc) Clearing procedure(2/2)
Figure A.5/B-IF2.02(Q.931)(7/9)
Overview protocol control (ISDN side)150

B-IF2.02-01-TSd) Resume procedure
Figure A.5/B-IF2.02(Q.931)(8/9)
Overview protocol control (ISDN side)

B-IF2.02-01-TS

151

10
ACTIVENOTIFYREQUESTNOTIFY10ACTIVEE) Suspend procedure
Figure A.5/B-IF2.02(Q.931)(9/9)
Overview protocol control (ISDN side)152

B-IF2.02-01-TS

B-IF2.02-01-TS

153

6

1
CALL INITIATED

SETUPCALL PRESENTSTART T312

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (1/27)

SETUP IND

CR SELECTION

START T303

SETUP

5.1.1

NULL

SETUP REQ

5.2.1

0

0
NULL

RELEASECOMPLETE

5.8.3.2 (C)154

B-IF2.02-01-TS

0

NULL

0
NULL

STATUS (CS=0)

RELEASERELEASECOMPLETE

5.8.11

NULL

5.8.3.2(b)00RELEASE(CAUSE#81)

19
RELEASEREQUEST

START T308

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (2/27)

NULL

RELEASECOMPLETE(CAUSE#81)

19

RELEASE(CAUSE#101)

RELEASEREQUEST

START T308

0

STATUS (CS°0)UNKNOWN OR
UNEXPECTEDMESSAGE

Releaseoption5.8.11

5.8.3

NULL

RELEASECOMPLETE(CAUSE#101)

B-IF2.02-01-TS

155

RELEASECOMPLETE

RELEASE CR

CALL PROCEEDING(B CHANNEL)

3
OUTGOING CALLPROCEEDING

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (3/27)

NULL

RELEASE(B-CHANNEL)

CONNECT(B-CHANNEL)0

REJ REQ

5.3.2(a)CALL INIT

PROC REC

5.1.5.1

1

11
DISCONNECT
REQUESTDISCONNECT IND

STOPALL TIMERSDISCONNECT

5.3.3

156

B-IF2.02-01-TS
Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (4/27)

B-IF2.02-01-TS

157

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (5/27)

158

B-IF2.02-01-TS
ALERTING

4
CALL DELIVEREDPROGRESS

3
OUTGOING CALLPROCEEDING

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (6/27)

ALERTING REQ

5.1.7

PROGRESS REQ

5.1.6

3
OUTGOING CALLPROCEEDING10ACTIVECONNECT

SETUP REQ

5.1.8

B-IF2.02-01-TS

159

10

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (7/27)

4
CALL DELIVEREDPROGRESSCONNECT

ACTIVEPROGRESSREQUEST

5.1.6

SETUP RES

5.1.8

4
CALL DELIVERED160

B-IF2.02-01-TS
STOP T312

START T310

CALL
PROCEEDINGIND

REJECT IND

RELEASE(B-CHAN AND CR)

09
INCOMING CALLPROCEEDINGSTOP T303

STOP T303

NULL

CALL
PROCEEDING

5.2.5.2

REL COMPLETE(CAUSE)

5.2.2

6

5.2.1

Detailed protocol control (INDN side)F
9/27

TIMEOUT T303

Figure A.6 / B-IF2.02 (Q.931) (8/27)

22
CALL ABORTSTOP T303

RELEASE REQ

5.2.5.4

CALL PRESENTDISCONNECT
REQ

5.3.4

B-IF2.02-01-TS

161

6

STOP T312

22
CALL ABORT

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (9/27)

CALL PRESENTSTART T303
T312

SETUP

Y

First timeout

8/27

RELEASE IND

N

5.2.1

F

162

B-IF2.02-01-TS

NC

22/27

TIMEOUT T301

22/27

CONNECTREQUEST

Detailed protocol control (INDN side)

Note: T301 is optional (see 9.1)

22/27

NR

RELEASEREQDISCONNECT
REQ

NC

5.2.5.4

5.3.4

Figure A.6 / B-IF2.02 (Q.931) (10/27)

8

SETUP
CONFIRM

STOP T301

CONNECTDISCONNECT(CAUSE)

ND

5.2.7

5.3.3

7
CALL RECEIVED

14/27

B-IF2.02-01-TS

163

22/27

ACTIVE

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (11/27)

10

CONNECT ACK

NC
22/27

DISCONNECT
REQ(SETUP COMPREQUEST)DISCONNECT(CAUSE)

ND

5.3.4

5.2.3

CONNECTREQUEST

5.3.3

8

164

B-IF2.02-01-TS

INCOMING
CALL PROCEEDING

9ND

STOP T310

PROG
INDICATIONDISCONNECT

PROGRESS(INTERWORKING)

22/27

5.3.3

5.2.6

8
CONNECTREQUEST

Note: T301 is optional (see 9.1)

Detailed protocol control (INDN side)

22/27

TIMEOUT T310

DISCONNECT
REQ

NC

5.2.5.3

5.3.4

Figure A.6 / B-IF2.02 (Q.931) (12/27)

7
CALL RECEIVED

START T301

(Note)SETUP
CONFIRM

STOP T310

STOP T310

ALERTING IND

CONNECT

5.2.5.2

ALERTING

5.2.5.1

INCOMING
CALL PROCEEDING

9

NR
14/27

RELEASE REQ

5.2.5.4

B-IF2.02-01-TS

165

ACTIVE

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (13/27)

10
ACTIVENOTIFYNOTIFYREQUEST

CONNECT ACK

10

5.6.4, 5.6.2, 5.9

ACTIVE

5.1.8

10

166

B-IF2.02-01-TS
RELEASEREQUEST

STOP T308

RELEASERELEASEREQUESTDISCONNECT
REQUEST

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (14/27)

19

11

NR
10/27, 12/27, 15/27

B-IF2.02-01-TS

167

0
NULL

RELEASE CALLREFERENCERELEASECOMPLETE

RELEASE
B-CHANNEL
14/27

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (15/27)

NR

STOP T305 or T306

RELEASEINDICATIONSTOP T305 or T306

DISCONNECT

5.3.5

DISCONNECT
INDICATIONRELEASE

5.3.4

12

NR
14/27

TIMEOUT T305 or
T306

5.3.4

168

B-IF2.02-01-TS
Note

Y

11
DISCONNECT
REQUEST

START T305

DISCONNECT(CAUSE)STATUS(ERROR)
INDICATIONNCOMPATIBLE
STATE

m=0

STATUS(CS=m)

5.8.11ANY STATEEXCEPT 0.19

Y

Detailed protocol control (public CS side)

Figure A.3/B-IF2.02 (Q.931) (16/24)

Note : Action on receipt of STATUS indicating a compatible
call state is implementation dependent(see 5.8.11)

REMAIN IN
CURRENTSTATESTATUSSTATUSENQUIRY

5.8.10ANY STATE0NULL

RELEASE CALLREFERENCESTATUS
INDICATIONB-IF2.02-01-TS

169

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (17/27)

170

B-IF2.02-01-TS

19

0

0

RELEASE
B-CHANNEL&CALL
REFERENCERELEASE
B-CHANNEL&CALL
REFERENCE

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (18/27)

NULL

RELEASECONFIRM

STOP T308

NULL

STOP T308

STATUS
INDICATION(ERROR)RELEASERELEASECOMPLETESTATUS (CS=0)

STATUS (CS°0)

RELEASEREQUEST

5.3.5

5.3.3

5.8.11

5.8.1119
RELEASEREQUEST

START T308

RELEASEYFIRST TIMEOUTTIMEOUT T308

5.3.4.3

19
RELEASE REQUEST

N

0
NULL

RELEASE CALLREFERENCERELEASECONFIRM(ERROR)

PLACE BCHANNEL IN
MAINTENANCE

B-IF2.02-01-TS

171

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (19/27)

172

B-IF2.02-01-TS
NR
22/27

STATUS
INDICATION(ERROR)N

COMPATIBLE
STATE

N

M=0

STATUS (CS=M)

5.8.11ANY STATE EXCEPT
0, 19

Y

Note

Y

0
NULL

STATUS
INDICATIONRELEASE CALLREFERENCE ANDRESOURCE

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (20/27)

Note: Action on receipt of STATUS indicating a compatible call state is implentation dependent (see 5.8.11)

REMAIN IN
CURRENT STATESTATUSSTATUS ENQUIRY

5.8.10ANY STATEB-IF2.02-01-TS

173

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (21/27)

174

B-IF2.02-01-TS
11
DISCONNECT
REQUESTDISCONNECT
INDICATIONDISCONNECT(B-CHANNEL)

STOP ALL TIMERSDISCONNECT

5.3.3

ANY STATEEXCEPT 0, 11, 12, 19,
22

11
DISCONNECT
INDICATION11DISCONNECT
INDICATIONDISCONNECT (P1)

START T305

START TONESTART T306

Y

Detailed protocol control (INDN side)

Note: See 9.1 for default values of T306

8/27, 10/27, 11/27, 12/27, 20/27

DISCONNECTDISCONNECT(B-CHANNEL)N

TONE OPTIONSTOP ALL TIMERS

NR

Figure A.6 / B-IF2.02 (Q.931) (22/27)

10/27, 11/27, 12/27

ND

DISCONNECT
REQUEST

5.3.4

ANY STATEEXCEPT 0, 6, 7, 8,
9, 11, 12, 19, 22

B-IF2.02-01-TS

175

STATUS(CAUSE #101)

STATUS ENQUIRY

0

0
NULL

RELEASECALL REFERENCE& B-CHANNELRELEASEINDICATIONRELEASECOMPLETE

5.8.4

ANY STATEEXCEPT 0, 19, 22

Note: Except RELEASE or RELEASE COMPLETENULLRELEASE CALLREFERENCE

Error handling SDL diagram (1/2)
Figure A.6 / B-IF2.02 (Q.931) (23/27)
Detailed protocol control (INDN side)

REMAIN IN
CURRENT STATESTATUS (CAUSE #98)

RELEASECOMPLETE

RELEASEINDICATIONSTOP ALLTIMERSRELEASE

5.8.4

STATUS (CAUSE #97)

STATUSENQUIRY OPTIONUNRECOGNIZEDMESSAGE

5.8.4

CAUSE OPTIONNote

UNEXPECTEDMESSAGE

5.8.4

ANY STATEEXCEPT 0, 12, 19, 2
2

RELEASE
B-CHANNEL

REMAIN IN
CURRENT STATE

SETUP

5.8.3.2(C)ANY STATEEXCEPT 0, 22

176

B-IF2.02-01-TS

0

NULL

0
NULL

RELEASECOMPLETE(CAUSE#100)

RELEASECOMPLETE(CAUSE#96)

0

SETUP WITH
MANDATORY
I.E. ERROR

5.8.6.2

0

SETUP W/O
MANDATORY I.E.

5.8.6.1

NULL

REMAIN IN
CURRENT STATE

11
DISCONNECT
REQUEST

NULL

Note

REMAIN IN
CURRENT STATESTATUS(CAUSE#100)

MESSAGE WITH
MANDATORY I.E.
ERROR

5.8.6.2

Note: Except SETUP, RELEASE and DISCONNECT

0

RELEASE CALLREFERENCERELEASEINDICATIONRELEASECOMPLETE(CAUSE #100)

RELEASE WITH
CAUSE I.E. ERRORDISCONNECT
WITH
CAUSE I.E. ERRORDISCONNECT
INDICATION

5.8.6.2

5.8.6.2

Error handling SDL diagram (2/2)
Figure A.6 / B-IF2.02 (Q.931) (24/27)
Detailed protocol control (INDN side)

NULL

RELEASE CALLREFERENCERELEASEINDICATIONSTATUS(CAUSE#96)

RELEASECOMPLETE(CAUSE#96)

DISCONNECT
INDICATIONDISCONNECT
REQUESTMESSAGE W/OMANDATORY I.E.

RELEASE W/O
CAUSE I.E.

DISCONNECT W/O
CAUSE I.E.

11

5.8.6.1

5.8.6.1

5.8.6.1

SPECIFIC STATEB-IF2.02-01-TS

177

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (25/27)

Note: The relevant states are as follows: N1, N3-N4, N6-N12, N19

REMAIN IN
CURRENT STATEDL-ESTABLISHINDICATION

5.8.8

RELEVANTSTATES (Note)178

B-IF2.02-01-TS
NULL

DL-RELEASEINDICAITONNo text

NULL

Note: Any times including T309

00Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (26/27)

0
NULL

DL-ESTABLISHREQUEST0NULLSTART T309(90S)

NO

TIMER
RUNNING

Note

RELEASE CALLREFERENCE

STOP ALLTIMERSDL-RELEASEINDICATION

5.8.8

ANY STATESEXCEPT 0

YES

B-IF2.02-01-TS

179

STATUS

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (27/27-1)

REMAIN IN
CURRENT STATESTATUS ENQUIRY0DATA LINKFAILURE
INDICATIONSTOP T309

NULL

RELEASE CALLREFERENCETIMEOUT T309

5.8.8

DL-ESTABLISHCONFIRM

5.8.8

ANY STATES180

B-IF2.02-01-TS

0

22

NULL

RELEASE CALLREFERENCE

T312 TIME OUTCALL ABORT22
CALL ABORTDISCONNECT
REQUESTRELEASEREQUEST

19
RELEASEREQUEST

Detailed protocol control (INDN side)

Figure A.6 / B-IF2.02 (Q.931) (27/27-2)

19

START T308

START T308

NULL

RELEASE CALLREFERENCERELEASERELEASE

0

RELEASE COMPLETE

STOP ALL TIMERSUNEXPECTEDMESSAGESTOP ALL TIMERSDISCONNECT
INDICATIONDISCONNECT

STOP ALL TIMERSDISCONNECT
INDICATIONCALL PROC

UNRECOGNIZEDMESSAGEAnnex B

Compatibility and address checking(This annex forms an integral part of this specification)
B.1 Introduction
This annex describes the various compatibility and address checks which should be carried out toensure that best match of user and network capabilities is achieved on a call within a network.
This annex also covers interworking with existing networks.
Three different processes of checking shall be performed:i) at the public cell station-to-ISDN interface on the calling side (see B.2);ii) at the ISDN-to-public cell station interface on the called side (see B.3.2); andiii) user-to-user (see B.3.3).
Note:

In this context and throughout this annex the term "called user" is the endpoint entity whichis explicitly addressed. This may be an addressed interworking unit (IWU); see the I.500Series Recommendations.

For details on the coding of the information required for compatibility checking see Annex I.
B.2 Calling side compatibility checking
At the calling side, the ISDN shall check that the bearer service requested by the calling public cellstation in the Bearer capability information element matches with the bearer services provided to thatpublic cell station by the ISDN.
Network services are described in Recommendations I.230 [47] as bearer services.
B.3 Called side compatibility and address checking
In this subclause, the word "check" means that the user examines the contents of the specified
information element.
B.3.1 Checking of addressing information
If an incoming SETUP message is offered with addressing information (i.e. either sub-addressing or
the appropriate part of the called party number), the following actions will occur:a) If a number or sub-address is assigned to a destination side, then the information in a Called party
number or Called party subaddress information element of the incoming call shall be checked by
the called side against the corresponding part of the number assigned to the called side or thecalled side’s own sub-address. In case of a mismatch, the called side shall ignore the call. In thecase of match, the compatibility checking described in B.3.2 through B.3.3 will follow.

B-IF2.02-01-TS

181b) If a called side has no assigned number or sub-address, then the Called party number and Called
party subaddress information element shall be ignored. Then, compatibility checking described in
B.3.2 and B.3.3 will follow.
Note:

According to called side’s requirements, compatibility checking can be performed in various
ways from the viewpoint of execution order and information to be checked, e.g. first assigned
number/sub-address and then compatibility or vice versa.

B.3.2 ISDN-to-public cell station compatibility checking
When the ISDN is providing a bearer service at the called side, the public cell station shall check thatthe bearer service offered by the ISDN in the Bearer capability information element matches thebearer services that the public cell station is able to support. If a mismatch is detected, then the public
cell station shall either ignore or reject the offered call using cause No. 88, incompatible destination(see 5.2.2).
B.3.3 User-to-user compatibility checking
The called side endpoint entity shall check that the content of the Low layer compatibility information
element is compatible with the functions it supports.
The Low layer compatibility information element (if available) shall be used to check compatibility of
low layers (e.g. from layer 1 to layer 3, if layered according to the OSI model).
If the Low layer compatibility information element is not included in an incoming SETUP message,
the Bearer capability information element shall be used to check the compatibility of low layers.
The called endpoint entity may check the High layer compatibility information element (if present) as
part of user-to-user compatibility checking procedures, even if the network only supports bearer
services.
If a mismatch is detected in checking any of the information elements above, then the endpoint entity
shall either ignore or reject the offered call using cause No. 88, incompatible destination (see 5.2.2).

182

B-IF2.02-01-TSB.3.4 Called side action tables
Tables B.1, B.2 and B.3 show the action which shall be carried out as a result of compatibility
checking with the calling side’s request for a bearer service.
Table B.1/B-IF2.02(Q.931)
Bearer capability compatibility checking
BC mandatory info element

Point-to-point data link
(Note 1)
ProceedCompatible
Incompatible

Ignore [5.2.5.1 a)] Reject (5.2.5.1)(Note 2)

Broadcast data link
(Note 1)
ProceedIgnore [5.2.5.1 a)](Note 2)

Reject [5.2.5.1 b)](Note 2)

Table B.2/B-IF2.02(Q.931)
Low layer and high layer compatibility checking –Compatibility assured with the available description of the call
LLC/HLC
Point-to-point data link
Broadcast data link
Compatibility assured(Note 1)
(Note 1)Compatible
AcceptAcceptRejectAttempt low
Incompatible
IgnoreRejectAttempt low Ignore[5.2.5.1 a)] [5.2.5.1 b)] layer[5.2.5.1 a)] (5.2.5.1)
layer(Note 2)compatibility(Note 2)compatibility (Note 2)
negotiation
negotiation(Annex J)(Annex J)

Table B.3/B-IF2.02(Q.931)
Low layer and high layer compatibility checking –Compatibility not assured with the available description of the call
LLC/HLC
Compatibility notassuredHLC or LLC
Present

Point-to-point data link
(Note 1)
Accept or reject(Note 3)

Attempt low layercompatibility
negotiation(Annex J)

Broadcast data link
(Note 1)
Accept or reject(Note 3)

Attempt low layercompatibility
negotiation(Annex J)

Notes to Tables B.1, B.2 and B.3
Note 1: For broadcast data link endpoint entity which is explicitly addressed using sub-addressing or theappropriate part of the called party number, the point-to-point column in the above table shall be used.
Note 2: When a endpoint entity on a broadcast data link is incompatible, an option of "ignore or reject" ispermitted (see 5.2.2).
Note 3: Some endpoint entity on this interface may understand the High layer compatibility or Low layercompatibility information elements and would reject the call if incompatible.

B-IF2.02-01-TS

183

B.4 Interworking with existing networks
Limitations in network or distant user signalling (e.g. in the case of an incoming call from a PSTN ora call from an analogue terminal) may restrict the information available to the called side in theincoming SETUP message. A called side should accept limited compatibility checking (e.g. without
the High layer compatibility information element) if a call is routed from an existing network which
does not support High layer compatibility information element transfer.
In cases where the network cannot provide all incoming call information, or where the network is notaware of the existence or absence of some service information (such as a compatibility information),
the incoming SETUP message includes a Progress indicator information element, containing progress
indicator No. 1, call is not end-to-end ISDN; further call progress information may be available inband, or No. 3, origination address is non-ISDN.
The endpoint entity receiving a SETUP with a Progress indicator information element shall modify its
compatibility checking, the endpoint entity should regard the compatibility as successful if it iscompatible with the included information, which as a minimum, will be the Bearer capability
information element. A terminal equipment expecting information in addition to the Bearer capability
information element need not reject the call if such information is absent but a Progress indicator
information element is included.

184

B-IF2.02-01-TS

Annex C
Transit network selection *B-IF2.02-01-TS

185

Annex D
Extensions for symmetric call operation *186

B-IF2.02-01-TS

Annex E
Network specific facility selection *B-IF2.02-01-TS

187

Annex F

D-channel backup procedures(This annex forms an integral part of this specification)
F.0 Foreword
The procedure defined in this annex can be used when non-associated signalling is applied to multiple
primary rate access arrangements. This feature can be provided on a subscription basis and is network
dependent.
F.1 General
In associated signalling, the D-channel signalling entity can only assign calls to channels on theinterface containing the D-channel. When the D-channel signalling entity can assign calls to channels
on more than one interface (including the one containing the D-channel), this is called non-associatedsignalling. Figure F.1 is an example of associated signalling used on each of the three interfaces
between a public cell station and a ISDN. Replacing associated signalling with non-associatedsignalling on these interfaces results in the example shown in Figure F.2.
When non-associated signalling is employed, the reliability of the signalling performance for the
ISDN interfaces controlled by the D-channel may be unacceptable. To improve the reliability, a Dchannel backup procedure employing a standby D-channel is necessary. The next subclause describes
the backup procedure which is optional for end-points that use non-associated signalling.
PBX

Primary rate interfaces

D-channels

Network

T1161370-94/d074

Figure F.1/Q.931
Example of associated signaling on each of the three primary rate interfaces

188

B-IF2.02-01-TS

Three primary rate interfaces controlled by D-channel
PBX

Network

T1161380-94/d075

D-channels

Figure F.2/Q.931
Example of non-associated signaling controlling three primary rate interfaces
F.2 D-channel backup procedure
F.2.1 Role of each D-channel
When two or more interfaces connect a ISDN and a public cell station, a primary D-channel (labelled"one") is always present on one interface. On a different interface, a secondary D-channel (labelled"two") is present that can also send signalling packets. Figure F.3 shows the addition of a secondary(i.e. backup) D-channel to the arrangement shown in Figure F.2.
D-channel one is used to send signalling packets across the public cell station-ISDN interface formultiple interfaces including the interface containing D-channel two. D-channel two is in a standbyrole and is active at layer 2 only. All SAPI groups (e.g. 0, 16 and 63) are alive and can send packets.
At periodic intervals determined by the appropriate layer 2 timer associated with SAPI 0, a link audit
frame will be sent on the point-to-point signalling link with DLCI = 0 of D-channel two.
Since D-channel two is in a standby role, load sharing between D-channels one and two is notpossible. Furthermore, D-channel two can not serve as a B-channel when it is in a standby role. Lastly,
D-channel two can only back up the signalling functions provided by D-channel one and not someother D-channel on a different interface.
Three primary rate interfaces controlled by D-channel
PBX

Network

T1161390-94/d076

Backup D-channelPrimary D-channel

Figure F.3/Q.931
Example of non-associated signaling with backup D-channel controlling three primary rateinterfaces

B-IF2.02-01-TS

189

F.2.2 Switchover of D-channels
Failure of D-channel one is determined by the receipt of a DL-RELEASE indication primitive fromthe data link layer. At this point, optionally additional attempts to re-establish this D-channel may beinitiated. Otherwise, it is assumed that D-channel one has failed.
Two states are defined for any D-channel in a backup arrangement. A D-channel is termed out-ofservice when layer 2 remains in the TEI-assigned state, after being periodically requested by layer 3 toestablish multiple-frame operation. A D-channel is termed maintenance busy when layer 2 is held in
the TEI-assigned state by layer 3. While in the maintenance busy condition, the response to an
invitation for link establishment is met with the transmission of a DM (Disconnected Mode).
When the D-channel one has failed and if D-channel two is not in an out-of-service condition, thelayer 3 shall place D-channel one in a maintenance busy condition, start timer T321 and then issue a
DL-ESTABLISH request primitive to re-initialize SAPI 0 link 0 of D-channel two. Upon receipt of
this primitive, the data link layer issues an SABME command. Timer T200 is started. The end
receiving the SABME command on D-channel two follows the remainder of the Q.931 procedures forestablishing logical link with DLCI = 0.
Once the logical link with DLCI = 0 in D-channel two is in the Link Established state, the procedure
to establish layer 3 call control signalling can begin on the link.
To establish the backup D-channel for carrying call control signalling, layer 3 should issue anappropriate layer 3 message (e.g. a STATUS ENQUIRY on stable call reference numbers). Once a
response to that layer 3 message is received, D-channel two is declared to be the active D-channel,
normal layer 3 call control signalling may proceed, timer T321 is stopped, and D-channel one is
moved to the out-of-service condition. If the maintenance busy timer T321 expires before a responseisreceived
to
the
layer
3
message, D-channel
one
is
moved
to
the
out-of-service condition and an attempt is made to establish the logical link with DLCI = 0
on D-channel one and D-channel two.
If the logical link with DLCI = 0 of both D-channel one and D-channel two are initialized
simultaneously, the designated primary shall be chosen as the D-channel for carrying call control
signalling. The designated primary D-channel is agreed upon at subscription time by both sides of theinterface.
After a switchover, old D-channel two becomes the new D-channel one and old D-channel one
becomes the new D-channel two.
Upon completion of appropriate maintenance activity to D-channel two, the logical links for SAPI = 0
and 63 are made active at layer 2 and the D-channel is removed from the out-of-service condition.
D-channels may only be switched again by a failure of D-channel one or a routing or maintenancerequest from a peer entity.

190

B-IF2.02-01-TS

Annex G
Use of progress indicators *B-IF2.02-01-TS

191

Annex H

Message segmentation procedures(This annex forms an integral part of this specification)
This optional procedure is used on the basis of bilateral agreement between the public cell station andthe ISDN.
H.1 Introduction
Layer 3 messages that are longer than the length of frames that the data link layer can support may bepartitioned into several segments.
Message segmentation shall only be used when the message length exceeds N201 (defined in
Recommen-dation Q.921 [3]).
The architectural relationship to other Q.931 functions is shown in Figure H.1. These procedures
apply only within a specific data link connection and do not impact the procedures in operation onother parallel data link connections.
In order to support expressed needs for applications requiring message lengths of 10 000 octets, orgreater, procedures to support those applications are under study. These procedures will consider
backward compatibility and methods to allow information on other call references to be interleavedwith segments of a long message. The specifics of these procedures are for further study.

Q.931
protocolcontrol

Integrated d CEI-call reference
multiplexer/demultiplexer

Layer 3Layer 2

Optional
Q.931
segmenter

Optional
Q.931
segmenter

Optional
Q.931
segmenter

Protocoldiscriminatorfilters
CEI
No. 1

CEI
No. 2

Broadcast
CEI

Figure H.1/Q.931
Logical architecture containing segmentation function

192

B-IF2.02-01-TS

T1161410-94/D078

H.2 Message segmentation
The following rules apply when Q.931 messages are to be segmented for transmission:a) The default maximum number of message segments is 8. If the message is too long to besegmented then a local maintenance activity shall be notified.
b) The first message segment shall begin with the Protocol discriminator information element
immediately followed by the Call reference information element, the segment message type, theSegmented message information element, and octets starting with the first octet following themessage type of the message being segmented, subject to the maximum length of the segment notexceeding the maximum size of the data link layer information field.
c) Each subsequent message segment shall begin with the Protocol discriminator information
element immediately followed by the Call reference information element, the segment message
type, the Segmented message information element, and one or more octets starting with the firstoctet following the message type of the message being segmented, subject to the maximum lengthof the segment not exceeding the maximum size of the data link layer information field.
d) The first segment indicator field of the Segmented message information element shall be set toindicate the first segment of a segmented message, and not set in any other segment.
e) The number of segments remaining field of the Segmented message information element shall be
set to indicate how many more segments are to be sent, see Figure H.2.
f)

The Message type information element shall be coded to indicate a segment message, and theSegmented message information element shall indicate the message type of the original message.

g) The transmission of a segmented message may be aborted by sending a message or message
segment containing a different call reference; sending a message with the message type not coded"segment message", or stopping the transmission of subsequent message segments pertaining to
the same message.
h) Once the first segment has been transmitted on a particular data link connection, then all
remaining segments of that message shall be sent (in order) before any other message (segmented
or not) for any other call reference is sent on that data link connection.
i)

The octet order for the segmented message shall be preserved regardless of segment boundary.

H.3 Reassembly of segmented messages
The following rules apply to the receipt and reassembly of segmented Q.931 messages:a) A reassembly function, on receiving a message segment containing the Segmented message
information element with the first segment indicator indicating "first message", and containing thecall reference and message type (coded as "segment message") shall enter the Receiving
Segmented Message state and accumulate message segments.

B-IF2.02-01-TS

193b) Timer T314 shall be initialized or re-initialized upon receipt of a message segment containing theSegmented message information element with a non-zero number of segments remaining field.
Timer T314 shall be stopped upon receipt of the last segment, i.e. a message segment containing
the Segmented message information element with the number of segments remaining field codedzero. Timer T314 shall not be initialized or re-initialized if error procedures as identified in rules
below are initiated.
c) A reassembly function receiving a message segment with a Segmented message information
element should wait for receipt of the last message segment pertaining to the same message, i.e.
containing the Segmented message information element with the number of segments remaining
field coded zero before delivering the message for further Q.931 processing as specified in 5.8.
The reassembly function shall enter the Null state.
d) Upon expiry of timer T314, the reassembly function shall discard all segments of this message so
far received; notify the layer 3 management entity for the data link connection that message
segments have been lost and enter the Null state.
Note 1: Subsequent message segments relating to the same message shall be discarded according torule f).

194

B-IF2.02-01-TS

Before segmentation

After segmentation

Protocol discriminatorProtocol discriminator

Call reference

Call reference

Message type=A

Message type=segment

Octet No. 1

Segmented message(1st, N–1, A)••

Octet No. 1••

Octet No. k
Octet No. k+1

Octet No. k••

Octet No. z

Protocol discriminator

Octet No. z+1

Call reference••

Message type=segment
Segmented message(Subsequent, N–2, A)

Octet No. m

Octet No. k+1••
Octet No. z••
Protocol discriminator
Call reference
Message type=segment
Segmented message(Subsequent, O, A)
Octet No. z+1••
Octet No. m
Note: Segmentation may occur at any octet boundary.

T1161420-94/do79

Figure H.2/Q.931
Relation between Message and Segments

B-IF2.02-01-TS

195e) A reassembly function, upon receiving eight message segments of the same segmented message
without receiving a message segment with a number of segments remaining field of theSegmented message information element coded zero, shall discard all message segments so far
received; notify the layer 3 management entity for the data link connection that messages havebeen discarded, and enter the Null state.
Note 2: Subsequent message segments relating to the same message shall be discarded according torule f).
f)

A reassembly function, on receiving a message segment containing a Segmented message
information element, but with no call reference or Message type information element, while in the
Null state shall discard that message segment and remain in the Null state.

g) A reassembly function, on receiving a message segment containing a Segmented message
information element, while in the Receiving Segmented Message state with the number ofsegments remaining field that is not decremented from the number of segments remaining field in
the Segmented message information element of the previous message segment, shall discard all
segments of this message so far received, and enter the Null state.
Note 3: Subsequent message segments relating to the same message shall be discarded according torule f).
h) If there is a DL-RELEASE indication primitive or DL-ESTABLISH indication primitive received
while in the Receiving Segmented Message state, the reassembly function shall discard allreceived message segments so far received; forward the DL-RELEASE indication primitive or
DL-ESTABLISH indication primitive for further Q.931 processing, and enter the Null state.
i)A reassembly function, upon receiving a message segment with the first segment indicator of theSegmented message information element indicating "subsequent", while in the Null state, shalldiscard that message segment, and remain in the Null state.
Block diagram
Management
Layer 3Layer 3

Management
Layer 3

(Error)(see H.2 a)(DL-DATA request
DL-UNITDATA request)(Error)(see H.3)

Segmentation
process

Layer 3
(DL-DATA indication
DL-UNITDATA indication
DL-ESTABLISH indication
DL-RELEASE indication)

Reassembly
process(DL-DATA request
DL-UNITDATA request)(DL-DATA indication
DL-UNITDATA indication
DL-ESTABLISH indication
DL-RELEASE indication)
T1145290-92/d080

Figure H.3/Q.931
Segmentation Functional Interaction Diagram196

B-IF2.02-01-TS

0
NULL

ALL OTHERDL
PROMITIVESDL-(UNIT) DATAREQUEST:(message)

ALL OTHERDL
PROMITIVESMESSAGE>N201
OCTETS?

No

Yes
0

DIVIDE MESSAGE
AT OCTETBOUNDARIESDL-(UNIT) DATAREQUEST:(message segment)

0Yes>8 SEGMENTS?

No
INSERT SEGMENTEDMESSAGEINFORMATIONELEMENT AFTERMESSAGE TYPENOTIFY LAYER 3
MANAGERDL-(UNIT) DATAREQUEST:(message segment)

0
T1145300-92/d081

No
LAST SEGMENT
SENT?

Yes
0

Figure H4/Q931
Message Segmenter SDL

B-IF2.02-01-TS

197

0
NULL

DL-(UNIT) DATA
INDICATION(message or message
segment)

ALL OTHER DL
PROMITIVES

A

B
2

CALL
REFERENCE
AND MESSAGE TYPE
(WITH VALUE=SEGMENT)
FOUND AFTERPROTOCOL DISCRIMINATOR?

2NoALL OTHER DL
PROMITIVES

Yes
SEGMENTEDMESSAGE IE
IMMEDIATELYFOLLOWING?

DL-(UNIT) DATA
INDICATION(message)

No

T1161430-94/d082

Yes
0
FIRST SEGMENT
INDICATOR=FIRST?

No

Yes
NUMBER OF
SEGMENTSREMAINING
< 8?

No

Yes
ACCUMULATEFIRST SEGMENTDISCARDSTORE CALL REF.

0

N m NUMBER OFSEGMENTSREMAININGSET T314(now + 4s)

1

Figure H.5/Q931 (Sheet 1 of 3)
Message Reassembler SDL

198

B-IF2.02-01-TS

0

0
NULL

DL-(UNIT) DATA
INDICATION(message or message
segment)

ALL OTHER DL
PRIMITIVES

T314 EXPIRYSTOP T314

DISCARDCALL
REFERENCE-SEVEDCALLED
REFERENCE?

No

Yes
No
MESSAGE TYPE=
SEGMENT?
DISCARD

Yes

NULL
No

STOP T314

SEGMENTEDMESSAGE IE
NEXT
ELEMENT?

B

DISCARD

Yes

1
No

FIRST
SEGMENT
INDICATOR=
SUB?

A

Yes
No

1

NUMBER OF
SEGMENTSREMAINING=
N–1?
Yes
NUMBEROF SEGMENTS
REMAINING
=0?

No

Yes
STOP T314

STOP T314
ASSEMBLEMESSAGESET (T314, now+4s)
ACCUMULATESEGMENTDISCARDDL-(UNIT) DATA
INDICATION(assembled message)

Nm N m N

001
T1161440-94/d083

Figure H.5/Q931 (Sheet 2 of 3)
Message Reassembler SDL

B-IF2.02-01-TS

199

DISCARDDISCARD CALL
ACCUMULATEDSEGMENTSNOTIFY LAYER 3
MANAGERT1161450-94/d084

Figure H.5/Q931 (Sheet 2 of 3)
Message Reassembler SDL

200

B-IF2.02-01-TS

Annex I

Low layer information coding principles(This annex forms an integral part of this specification)
I.1 Purpose
This annex describes principles that shall be used when the calling side specifies information during
call set-up regarding low layer capabilities required in the network and by the destination side.
Note:

In this context and throughout this annex the term "called user" is the endpoint entity whichis explicitly addressed. This may be an addressed interworking unit (IWU) (see I.500-Series
Recommendations [51] and Recommen-dation X.31 [14] case A).

I.2 Principles
I.2.1 Definitions of types of information
There are three different types of information that the calling side may specify during call set-up to
identify low layer capabilities needed in the network and by the destination side:a) type I information is information about the calling terminal which is only used at the destination
end to allow a decision regarding terminal compatibility. An example would be modem type. This
information is encoded in octets 5 to 7 of the Low layer compatibility information element;b) type II information is the selection of bearer service from the choices of bearer services offeredby the ISDN to which the calling public cell station is connected. This type of information ispresent even if no interworking occurs. An example is unrestricted digital information (UDI).
This information is coded ini)octets 3 and 4 of the Bearer capability information element when the transfer mode requiredby the calling public cell station is circuit mode;ii) octets 3 and 4 of the Bearer capability information element when the transfer mode requiredby the calling public cell station is packet mode;Note:

Use of this transfer mode is for further study.

c) type III information is information about the terminal or intended call which is used to decidedestination terminal compatibility and possibly to facilitate interworking with other dedicatednetworks. An example is A-law encoding. This information is encoded in octet 5 of the Bearercapability information element.

B-IF2.02-01-TS

201

I.2.2 Examination by network
Type I information is user-to-user (i.e. not examined by network) while both types II and III should beavailable for examination by the destination public cell station and the ISDN. The Low layercompatibility information element is an information element which is not examined by the network
while the Bearer capability information element is an information element which is examined by the
public cell station and the ISDN.
I.2.3 Location of type I information
Type I information (i.e. terminal information only significant to the called side) shall, when used, be
included in the Low layer compatibility information element.
I.2.4 Location of type II and III information
Type II (i.e. bearer selection) information shall be included in the Bearer capability information
element. Type III information, when used, is included in the Bearer capability information element.
The ISDN may use and modify the information (e.g. to provide interworking). The rationale for theuser including some terminal related information in the type III information (interworking related) isshown by the following example.
Normally with UDI, the rate adaption technique chosen is related to the terminal. The specification ofa particular rate adaption scheme with a UDI bearer service could allow a compatibility decision by
the destination. However, it could also conceivably be used to allow interworking with a PSTN,
assuming that the appropriate functions (i.e. data extraction, modem pool) are available at theinterworking unit.
If the rate adaption information is carried in the Low layer compatibility information element, and notin the Bearer capability information element, then interworking by the ISDN providing the bearercapability would not be possible. However, if the rate adaption information is carried in the Bearercapability information element, interworking would be possible.
Hence, there is some terminal related information which may be considered interworking related. The
consequence for the calling side of not including such terminal related information in the Bearercapability information element is that the call may not be completed if an interworking situation is
encountered.

202

B-IF2.02-01-TS

Annex J

Low layer compatibility negotiation(This annex forms an integral part of this specification)
This annex describes an additional low layer compatibility checking procedure that may be applied by
the user. However, this procedure is a network option and may not be supported by all of ISDNs.
J.1 General
The purpose of the Low layer compatibility information element is to provide a means which should
be used for compatibility checking by an addressed entity (e.g. a remote user or an interworking unitor high layer function network node addressed by the calling user). The Low layer compatibility
information element is transferred transparently between the call originating entity (e.g. the callinguser) and the addressed entity.
The user information protocol fields of the Low layer compatibility information element indicate thelow layer attributes at the call originating entity and the addressed entity. This information is notinterpreted by the network and therefore the bearer capability provided by the network is not affectedby this information. The call originating entity and the addressed entity may modify the low layer
attributes by the negotiation described below if that can be supported by the bearer capability actuallyprovided by the network.
The Low layer compatibility information element is coded according to 4.5.19.
J.2 Low layer capability notification to the called user
When the calling user wishes to notify the called user of its information transfer attributes (type II
information – octets 3 and 4) or any low layer protocol (type I information - octets 5 to 7) to be usedduring the call and not already identified in the Bearer capability information element, then the callinguser shall include a Low layer compatibility information element in the SETUP message; this element
is conveyed by the network and delivered to the called user. However, if the network is unable toconvey this information element, it shall act as described in 5.8.7.1 (unrecognized information
element).
J.3 Low layer compatibility negotiation between users
If the negotiation indicator (see 4.5) of the Low layer compatibility information element included in
the SETUP message is set to "Out-band negotiation is possible (octet 3a, bit 7)", then one or more of
the low layer protocol attribute(s) may be negotiated. In this case, the called user responding
positively to the call may include a Low layer compatibility information element in the CONNECT
message. This element will be conveyed transparently by the network and delivered to the calling user
in the CONNECT message.
Note:

Only the low layer protocol attributes may be negotiated and therefore the informationtransfer attributes (octets 3 to 4), if returned by the called user in the CONNECT message,
will be identical to the ones received in the Low layer compatibility information element
contained in the SETUP message.

B-IF2.02-01-TS

203

If, for any reason, the network is unable to convey this information element, it shall act as described in
5.8.7.1 (unrecognized information element). Called users are advised not to include in the Low layercompatibility information element sent to the calling user, attributes which would have the same value
as the ones contained in the Low layer compatibility information element received from the calling
party.
J.4 Low layer compatibility negotiation options
The Low layer compatibility information element contains a negotiation indicator which may haveone of the following values:a) Out-band negotiation not possible (default) – Then the called user shall not invoke negotiation,according to J.3.
b) Out-band negotiation possible – The called user may then invoke low layer compatibility
negotiation, as needed, according to J.3.
c) In-band negotiation possible – The called user may then invoke low layer compatibility
negotiation using the supported in-band negotiation, according to service or application
requirements.
d) Either in-band or out-band negotiation allowed – The called user may invoke one or the otherlow layer compatibility negotiation procedures according to its requirements. If the out-band low
layer compatibility negotiation is supported by both of the end-to-end parties, then this method ofnegotiation is preferred.
J.5 Alternate requested values
If the user wishes to indicate alternative values of low layer compatibility parameters (e.g. alternative
protocol suites or protocol parameters), the Low layer compatibility information element is repeatedin the SETUP message. Up to four Low layer compatibility information elements may be included ina SETUP message. The first Low layer compatibility information element in the message is precededby the Repeat indicator information element specifying "priority list for selection". The order of
appearance of the Low layer compatibility information elements indicates the order of preference ofend-to-end low layer parameters.
Alternatively, the network may discard the lower priority Low layer compatibility information
element(s) depending on the signalling capability of the network.
If the network or called side does not support repeating of the Low layer compatibility information
element, and therefore discards the Repeat indicator information element and the subsequent Low
layer compatibility information elements, only the first Low layer compatibility information element
is used in the negotiation.
The called side indicates a single choice from among the options offered in the SETUP message by
including the Low layer compatibility information element in the CONNECT message. Absence of a
Low layer compatibility information element in the CONNECT message indicates acceptance of thefirst Low layer compatibility information element in the SETUP message.

204

B-IF2.02-01-TS

Annex K
Procedures for establishment of bearer connection prior to call acceptance *B-IF2.02-01-TS

205

Annex L
Optional procedures for bearer service change *206

B-IF2.02-01-TS

Appendix I

Definition of causes values(This appendix does not form an integral part of this specification)
Table I.2 indicates the usage of cause values within this specification. Other usage may be provided
within other Recommendations, e.g. Q.700-Series and Q.699. Other causes may also be used by
Q.931 entities where this is not precluded by the procedures defined elsewhere in this specification.
Table I.1 defines the key for the location of generation in Table I.2. For more precise usage of thelocation codes in the cause information element, see Recommendation Q.850.
Table I.1/B-IF2.02(Q.931)
Key to the location in Table I.2
LU
Local user
LN
Local network
TN
Transit network
RN
Remote network
RU
Remote user
LPE
Local peer entity (for symmetrical operation, see Annex D)
The following abbreviations to message types are used in Table I.2
CON CON CONGESTION CONTROLDISCDISCONNECTREL
RELEASEREL COM RELEASE COMPLETERES REJRESUME REJECTSTATSTATUSSUSP REJ SUSPEND REJECT

B-IF2.02-01-TS

207

208
B-IF2.02-02-TS

Table I.2/B-IF2.02(Q.931)
Usage of cause values

Cause No.

Class

Value

Cause name

Diagnostics

Reference

Typical locationof generation

Typical carrying message as identified
by receiving side
At remoteinterface

11

12

13

000

000

000

0001

0010

0011

Unassigned(unallocated) number

No route to specified
transit network

No route todestination

Condition

Transit network
identity/network specificfacilities info. elements
Condition

16

000

0110

Channel unacceptable

–

17

000

0111

–

16
17

001
001

0000
0001

Call awarded and being
delivered in an
established channel
Normal call clearing
User busy

Condition–

At localinterface
REL COM
DISC

5.1.4

LN

5.2.4

RU

C.2

TN

DISC

E.3
5.1.4

LN
LN

5.2.4

RU

REL COMDISCREL COM
DISC

5.2.3.1 c)
5.3.2 d)6.2.2.3.1
6.2.2.3.1

LN

REL

LN

REL

5.2.5.1
5.2.5.4 b)
No procedure

RU
RU
RN

REL COMDISCREL COMDISCDISCREL COM

DISC
DISC
DISC

Table I.2/B-IF2.02(Q.931) (cont.)

Cause No.

Class

Value

Cause name

Diagnostics

Reference

Typical locationof generation

18
19

001
001

0010
0011

–
–

5.2.5.3
5.2.5.3

RN
RN

20
21

001
001

0100
0101

No user responding
User alerting,no answer
Subscriber absent
Call rejected

001

0110

Number changed

5.2.5.4
5.2.5.1
5.2.5.4 b)
5.1.4

RN
RU

22

–
Condition: user supplieddiagnostic
New destination number

5.2.4

RU

5.3.2 b)6.2.2.3.1
5.8.9

LN

REL

RN
LN

DISC
DISC
REL COM
DISC

26

001

1010

27
28

001
001

1011
1100

Non-selected user
clearing
Destination out of order
Invalid number format(incomplete number)–––

Typical carrying message as identified
by receiving side
At remoteAt localinterfaceinterface
DISC
DISC

REL COM

LN

5.2.4

RU

5.1.5.2
5.2.4
5.1.4

LN
RN
LN

REL COMDISCDISCREL COM

DISC
DISC
DISC
REL COM
DISC

DISC
DISC
DISC
REL COM

B-IF2.02-02-TS
209

210
Table I.2/B-IF2.02(Q.931) (cont.)
B-IF2.02-02-TS

Cause No.

Class

Value

Cause name

Diagnostics

Reference

29

011

1101

Facility rejected

Facility identification

No procedure in
Q.931

Typical locationof generation

LN
RN
RU

30

001

1110

31

001

1111

34

010

0010

38

010

0110

Response to
STATUS ENQUIRYNormal, unspecified
No circuit/channel
available

Network out of order–

5.8.10

LU, LN

–

5.8.4

RN

–

5.1.1
5.1.2
5.1.5.1
5.1.5.2
5.2.3.1 b)
5.2.3.1 e)
5.2.3.2
6.2.2.3.1
C.2

LN

–

C.2
D.1.1 e)D.3 b)
No procedure

Typical carrying message as identified
by receiving side
At remoteAt localinterfaceinterface
REL COMDISCDISCREL COMDISCSTATREL COMDISCREL COMRU

REL COMDISCLN

REL COMDISCREL COMDISCDISCREL COMTN
LPE

Table I.2/B-IF2.02(Q.931) (cont.)
Typical locationof generation

Cause No.

Class

Value

Cause name

Diagnostics

Reference

41

010

1001

Temporary failure–

LU, LN
LN, RU, RN

42

010

1010

–

43

010

1011

Switching equipment
congestion
Access information
discarded

5.8.8
5.8.10No procedure
7.1.5.7

RU, LN, RU

7.1.6.1
5.8.7.2
5.1.2
5.1.5.1
5.1.5.2
5.2.3.1 e)
5.2.3.2
6.2.3.3.1
D.1.1 e)No procedure

LN
LN, LU
LN

44

47

010

010

1100

1111

Requestedcircuit/channel notavailable

Resource unavailable,
unspecified

Discarded into element
identifier(s)

–

–

RU

Typical carrying message as identified
by receiving side
At remoteAt localinterfaceinterface
DISC
DISC
DISC
REL
REL COM
CON CONSTATSTATREL COMREL COMDISCREL COM

B-IF2.02-02-TS
211

212
Table I.2/B-IF2.02(Q.931) (cont.)
B-IF2.02-02-TS

Cause No.

Class

Value

Cause name

Diagnostics

Reference

Typical locationof generation

57

011

1001

Bearer capability not
authorized

Attributes of bearercapability

5.1.5.2

LN

7.2.2

LN

5.1.5.2

LN

7.2.2

LN

–

5.1.5.2

LN

Attributes of bearercapability

5.1.5.2

LN
LN

Channel type

6.1
No procedure

Facility identification

7.1.3.6

RU

7.1.4.3
7.1.5.3
7.1.7.4

RN

58

011

1010

63

011

1111

65

100

0001

66

100

0010

69

100

0101

Bearer capability notpresently available

Service or option notavailable, unspecified
Bearer capability not
implemented
Channel type not
implemented
Requested facility not
implemented

Attributes of bearercapability

LN

Typical carrying message as identified
by receiving side
At remoteAt localinterfaceinterfaceDISC
REL COMRELREL COMDISCREL COMRELREL COMDISCREL COMDISCREL COMREL COMDISCREL COM

DISC
REL
DISC
REL
REL COM

Table I.2/B-IF2.02(Q.931) (cont.)
Typical locationof generation

Cause No.

Class

Value

Cause name

Diagnostics

Reference

70

100

0110

–

No procedure(network
dependent option)

79

100

1111

81

101

0001

Only restricted digital
information bearercapability is available
Service or option not
implemented,
unspecified
Invalid call reference
value

–

5.8.3.2 a)

LU, LN

Channel identity

5.8.3.2 b)
5.8.3.2 f)
5.1.4

LU, LN
LU, LN
LN

82

101

0010

83

101

0011

84
85
86

101
101
101

0100
0101
0110

Identified channel does
not exist
A suspended call exists,
but this call identity
does notCall identity in use
No call suspended
Call having therequested call identity
has been cleared

Typical carrying message as identified
by receiving side
At remoteAt localinterfaceinterface

–

5.6.5

LN

REL
REL COMREL COMSTATDISCREL COMRES REJ

–
–

5.6.3
5.6.5
5.6.5

LN
LN
LN

SUSP REJRES REJRES REJ

B-IF2.02-02-TS
213

214
Table I.2/B-IF2.02(Q.931) (cont.)
B-IF2.02-02-TS

Cause No.

Class

Value

Cause name

Diagnostics

Reference

88

101

1000

Incompatible destination

Incompatible parameter

91

101

1011

Invalid transit network
selection–

5.2.2
5.2.5.1
5.2.5.3 a)
B.3.2
B.3.3
C.2

95

101

1111

96

110

0000

97

110

0001

98

110

0010

99

110

0011

Invalid message,
unspecified
Mandatory information
element is missing

Message typenon-existent or
not implemented
Message not compatible
with call state or
messagetype non-existent or not
implemented
Information element
non-existent or not
implemented

Typical location ofgeneration

RU

Typical carrying message as identified
by receiving side
At remoteAt localinterfaceinterface
REL COM
DISC

TN

DISC

LN

5.8.6.1

LN, LU

LN, LU
LU, LN

Message type

5.8.11
5.8.4
5.8.105.8.11
5.8.4

DISC
REL
REL COMREL COMSTATRELREL COM
STAT
STAT
STAT

LU, LNSTAT

Information element
identifier(s)5.8.7.1
5.8.11

LU, LN

STAT

5.8.7.1

LN

REL
REL COM

Message type
Information element
identifier(s)Message type

5.8

LN

Table I.2/B-IF2.02(Q.931) (end)Cause No.

Class

Value

Cause name

Diagnostics

Reference

Typical location ofgeneration

100

110

0100

Invalid information
element contents

Information element
identifier(s)5.8.6.2

LU, LN

5.8.7.2
5.8.11
5.8.4

LU, LN
LN, LU

STAT

5.8.11

LN, LU

5.2.4
5.2.5.3
5.6.5
5.4.1
5.3.3
5.3.4
5.3.2 f)
5.3.3
5.6.5
5.8.4

LN

DISC
REL
REL COM
DISC

LN

REL

LU

REL

RN

DISC

101

102

110

110

0101

0110

B-IF2.02-02-TS

111

110

1111

127

111

1111

Message not compatible
with call state

Recovery on time expiry

Protocol error,
unspecified
Interworking,unspecified

Message type

Timer number

No explicit
procedure

Typical carrying message as identified
by receiving side
At remoteAt localinterfaceinterfaceSTAT
REL
REL COM
STAT215

Appendix II

Example message flow diagrams and example conditions for cause mapping *216

B-IF2.02-01-TS

Appendix III

Summary of assigned information element identifier and message type code points
for the Q.93x-Series and Q.95x-Series of Recommendations(This appendix does not form an integral part of this specification)
Table III.1/B-IF2.02(Q.931)
Information element code points
Bit
8 7
1 :
0
0
0
0
0
1
0 :
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1

6
:
0
0
1
1
1
0
:
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
0
0
0
0
0

5
:
0
1
0
0
1
1
:
0
0
0
0
0
1
1
1
1
1
1
0
0
0
0
0
0
1
1
1
1
1
1
1
1
0
0
0
0
0
0

4
0
0
:
0
0
1
1
1
0
0
1
1
1
1
0
0
0
1
1
1
0
0
0
0
1
1
1
1
0
0
0
0
0
0

3
0
0
:
0
1
0
1
1
0
1
0
0
1
1
0
1
1
0
0
1
0
0
1
1
0
0
0
0
0
0
0
0
1
1

2
0
0
:
0
0
0
0
0
0
0
0
0
0
1
0
0
1
0
0
0
0
1
0
1
0
0
1
1
0
0
1
1
0
0

Recommendationreference
1
0
1
:
0
0
0
0
1
0
0
0
1
0
0
0
0
1
0
1
0
0
0
0
0
0
1
0
1
0
1
0
1
0
1

Single octet information elements:
Reserved
Shift
More data
Sending complete
Congestion level
Repeat indicator
Variable length information elements:
Segmented message
Bearer capability
Cause
Connected address
Extended facility
Call identity
Call state
Channel identification
Data link connection identifier
Facility
Progress indicator
Network specific facilities
Terminal capabilities
Notification indicator
Display
Date/time
Keypad facility
Keypad echo
Information request
SignalSwitchhook
Feature activation
Feature indication
Service profile identification
Endpoint identifier
Information rate
Precedence level
End-to-end transit delay
Transit delay selection and indication
Packet layer binary parameters
Packet layer window size

Q.931
Q.931
Q.931
Q.931
Q.931
Q.931
Q.931
Q.931
Q.931
(Note 1)
Q.932
Q.931
Q.931
Q.931
Q.933
Q.932
Q.931
Q.931
(Note 1)
Q.931
Q.931
Q.931
Q.931
(Note 1)
Q.932 [4]Q.931
(Note 1)
Q.932
Q.932
Q.932
Q.932
Q.931
Q.955 (clause 3)
Q.931
Q.931
Q.931
Q.931

B-IF2.02-01-TS

217

Table III.1/B-IF2.02(Q.931) (end)
Bit

8 7 6
0 : :
1 0
1 0
1 0
1 0
1 0
1 0
1 0
1 0
1 0
1 0
1 0
1 1
1 1
1 1
1 1
1 1
1 1
1 1
1 1
1 1
1 1
1 1
1 1
Note 1:

Recommendationreference

5 4 3 2 1
: : : : :Variable length information elements:
0 0 1 1 0
Packet size
Q.931
0 0 1 1 1
Closed user group
Q.931
0 1 0 0 0
Link layer core parameters
Q.933
0 1 0 0 1
Link layer protocol parameters
Q.933
0 1 0 1 0
Reverse charging indication
Q.931
0 1 1 0 0Connected number
Q.951 [85]
0 1 1 0 1
Connected subaddress
Q.951
1 0 0 0 0
X.213 priority
Q.933
1 0 0 0 1
Report type
Q.933
1 0 0 1 1
Link integrity verification
Q.933
1 0 1 1 1
PVC status
Q.933
0 1 1 0 0
Calling party number
Q.931
0 1 1 0 1
Calling party subaddress
Q.931
1 0 0 0 0
Called party number
Q.931
1 0 0 0 1
Called party subaddress
Q.931
1 0 1 0 0
Redirecting number
Q.931, Q.952 [86]1 0 1 1 0
Redirection number
Q.952
1 1 0 0 0
Transit network selection
Q.931
1 1 0 0 1
Restart indicator
Q.931
1 1 1 0 0
Low layer compatibility
Q.931
1 1 1 0 1
High layer compatibility
Q.931
1 1 1 1 0
User-user
Q.931
1 1 1 1 1
Escape for extension
Q.931
These code points are reserved to ensure backward compatibility with earlier versions ofRecommendation Q.931.
Note 2: All reserved values with bits 5-8 coded "0000" are for future information elements for which
comprehension by the user is required (see 5.8.7.1).

218

B-IF2.02-01-TS

Table III.2/B-IF2.02(Q.931)
Message type code points
Bit

Recommendationreference

8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0
Escape to nationally specific message types
Q.931
0 0 0 - - - - Call establishment messages:
0 0 0 0 1
ALERTING
Q.931
0 0 0 1 0
CALL PROCEEDING
Q.931
0 0 0 1 1
PROGRESS
Q.931
0 0 1 0 1
SETUP
Q.931
0 0 1 1 1
CONNECT
Q.931
0 1 1 0 1
SETUP ACKNOWLEDGE
Q.931
0 1 1 1 1
CONNECT ACKNOWLEDGE
Q.931
0 0 1 - - - - Call information phase messages:
0 0 0 0 0
USER INFORMATION
Q.931
0 0 0 0 1
SUSPEND REJECT
Q.931
0 0 0 1 0
RESUME REJECT
Q.931
0 0 1 0 0
HOLD
Q.932 [4]0 0 1 0 1
SUSPEND
Q.931
0 0 1 1 0
RESUME
Q.931
0 1 0 0 0
HOLD ACKNOWLEDGE
Q.932
0 1 1 0 1
SUSPEND ACKNOWLEDGE
Q.931
0 1 1 1 0
RESUME ACKNOWLEDGE
Q.931
1 0 0 0 0
HOLD REJECT
Q.932
1 0 0 0 1
RETRIEVE
Q.932
1 0 0 1 1
RETRIEVE ACKNOWLEDGE
Q.932
1 0 1 1 1
RETRIEVE REJECT
Q.932
0 1 0 - - - - Call clearing messages:
0 0 0 0 0
DETACH(Note)
0 0 1 0 1
DISCONNECT
Q.931
0 0 1 1 0
RESTART
Q.931
0 1 0 0 0
DETACH ACKNOWLEDGE(Note)
0 1 1 0 1
RELEASE
Q.931
0 1 1 1 0
RESTART ACKNOWLEDGE
Q.931
1 1 0 1 0
RELEASE COMPLETE
Q.931
0 1 1 - - - - Miscellaneous messages:
0 0 0 0 0
SEGMENT
Q.931
0 0 0 1 0
FACILITY
Q.932 [4]0 0 1 0 0
REGISTER
Q.932
0 1 0 0 0
CANCEL ACKNOWLEDGE(Note)
0 1 0 1 0
FACILITY ACKNOWLEDGE(Note)
0 1 1 0 0
REGISTER ACKNOWLEDGE(Note)
0 1 1 1 0
NOTIFY
Q.931
1 0 0 0 0
CANCEL REJECT(Note)
1 0 0 1 0
FACILITY REJECT(Note)
1 0 1 0 0
REGISTER REJECT(Note)
1 0 1 0 1
STATUS ENQUIRY
Q.931
1 1 0 0 1
CONGESTION CONTROL
Q.931
1 1 0 1 1
INFORMATION
Q.931
1 1 1 0 1
STATUS
Q.931
Note: These code points are reserved to ensure backward compatibility with earlier versions of Recommendation
Q.931.

B-IF2.02-01-TS

219

Appendix IV Call procedure for the grouped multiple interfaces

In this system, when the Public CS is called, the ISDN shall send SETUP messages to the grouped
multiple interfaces equivalent to the paging zone. According to this procedure, this Appendix is
described to support to understanding of the behavior.
The ISDN calls for multiple interfaces, thus the number of calls that occur at the same time increases.
Therefore, the length of call reference shall be 2 octets. On the other hand, only one call is transferred
into active within the called multiple interfaces, the ISDN does not choice the channel for each Public
CS, and calls pointing an any channel.
Called Public CSs shall operate the procedure that describes from 5.8.1 to 5.8.7., and the ISDN shallinitiate the destination if the Public CS can continue the call. When Public CSs that cannot initiate the
Public CSs shall ignore the SETUP message. When a Public CS can initiate the destination but
confirm it cannot continue the call, the Public CS shall send RELEASE COMPLETE message to the
ISDN with some suitable cause (e.g. cause No. 65, Bearer capability not implemented, cause No. 21,
Call rejected). When a Public CS confirms it can continue the communication, but is initiateddisconnect of call from the destination, the Public CS shall initiate call clearing procedure to the ISDN
with the cause of disconnect. When the case, to be able to initiate the destination, to decide it is able tocontinue the communication, not to be initiated disconnect of call from the destination, the Public CS
shall return CALL PROCEEDING message to the ISDN.
The ISDN may receive some responses from plural Public CSs to a SETUP message.
When the ISDN receives requires of call continue from several Public CSs toward SETUP message
that the ISDN sent, the ISDN shall initiate call establishment to only the first Public CS that ischecked compatibility of call. At the time, the ISDN has checked compatibility of call, the ISDN shallinitiate call clearing procedure by RELEASE message with cause No. 26, Non-selected user clearing,to the other Public CSs that request call communication. After the ISDN has checked compatibility ofcall, at the case the ISDN receives request of communication from other Public CSs, if the timer
T312 is running, then the ISDN shall initiate the clearing of the Public CS by RELEASE message
with cause No. 26, Non-selected user clearing, or by DISCONNECT message with some suitablecause (example; cause No. 63, Service or option not available, unspecified). After the timer T312
expired, if the ISDN receives request of communication, then the ISDN shall initiate the clearing of
the Public CS by procedure described in Section 5.8.3.2, regarding the response has invalid callreference.
While a call is continue, the ISDN shall ignore RELEASE COMPLETE messages from the Public
CSs except the call connected Public CS. If the ISDN receives DISCONNECT messages or
RELEASE messages, the ISDN shall follow the interface rules, and these operations give no influence
the calls continue on the other interfaces. After re-sending SETUP message and before timer T303
expire, if the ISDN receives cause, the ISDN shall notify the cause to remote side. Several causes canbe sent according to protocol, the cause of which location indicates user precedes. If the ISDN does
not receive cause, cause No. 20, Subscriber absent, shall be sent.

220

B-IF2.02-01-TS

ACRONYMS USED IN THIS RECOMMENDATION

ABM
ACK
ADPCM
AFI
ARM
AU
BC
BCD
Bi
Bi`
Bj
CEI
CES
CSPDN
D
DDI
DLCI
DSP
DTE
HDLC
HLC
I
IA5
IDI
IE
IEC
ISDN
ISO
IWF
IWU
LAN
LAPB
LAPD
LLC
LLI
NACK
NIC
NRM
NSAP
NT2
OSI
PABX
PCM
PH
PSPDN

Asynchronous Balanced Mode (of HDLC)
Acknowledgement
Adaptive Differential Pulse Code Modulation
Authority and Format Identifier
Asynchronous Response Mode (of HDLC)
Access Unit
Bearer Capability
Binary Coded Decimal
Indicated B-Channel
An idle B-Channel Bi
A B-Channel in use
Connection Endpoint Identifier
Connection Endpoint Suffix
Circuit Switched Public Data Network
The D-Channel
Direct-Dialling-In
Data Link Connection Identifier (see Recommendations Q.920 and Q.921)
Domain Specific Part
Data Terminal Equipment
High Level Data Link Control (procedures)High Layer Compatibility
Information (frame)
International Alphabet No. 5 (defined by CCITT)
Initial Domain Identifier
Information Element
International Electrotechnical Commission
Integrated Services Digital Network
International Standard Organization
Interworking Function
Interworking Unit
Local Area Network
Link Access Protocol-Balanced
Link Access Protocol on the D-Channel
Low Layer Compatibility
Logical Link Identifier (see Recommendation Q.921)
Negative Acknowledgement
Network Independent Clock
Normal Response Mode (of HDLC)
Network Service Access Point
Network Termination of type two
Open System Interconnection
Private Automatic Branch Exchange
Pulse Code Modulation
Packet Handler
Packet Switched Public Data Network

B-IF2.02-01-TS

221

PSTN
PVC
RDTD
SABME
SAPI
SDL
TA
TE1
TE2
TEI
TID
UDI
UDI-TA
UI
USID
VC

Public Switched Telephony Network
Permanent Virtual Circuit
Restricted Differential Time Delay
Set Asynchronous Balanced Mode Extended (frame)
Service Access Point Identifier (see Recommendation Q.921)
Functional specification and description language
Terminal Adaptor (see Recommendation I.411)
Terminal Equipment of type 1 (see Recommendation I.411)
Terminal Equipment of type 2 (see Recommendation I.411)
Terminal Endpoint Identifier (see Recommendations Q.920 and Q.921)
Terminal identifier
Unrestricted Digital Information
Unrestricted Digital Information with Tones/Announcements
Unnumbered Information (frame)
User service identificator(Switched) Virtual Circuit

References
[1]
[2]
[3]
[4]
[5]

[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]

222

CCITT Recommendation ISDN user-network interface layer 3 – General aspects,
Rec. Q.930/I.450.
CCITT Recommendation ISDN user-network interface – Interface structures and accesscapabilities, Rec. I.412.
CCITT Recommendation ISDN user-network interface – Data link layer specification,
Rec. Q.921/I.441.
CCITT Recommendation Generic procedures for the control of ISDN supplementary
services, Rec. Q.932.
CCITT Recommendation Interface between data terminal equipment (DTE) and data circuit
terminating equipment (DCE) for terminals operating in the packet mode and connected to
public data networks by dedicated circuit, Rec. X.25.
CCITT Recommendation Circuit mode bearer service categories, Rec. I.231.
CCITT Recommendation Support of data terminal equipments (DTEs) with V-Series typeinterfaces by an integrated services digital network (ISDN), Rec. V.110.
CCITT Recommendation Support of X.21, X.21 bis and X.20 bis based data terminal
equipments (DTEs) by an integrated services digital network (ISDN), Rec. X.30.
CCITT Recommendation Support by an ISDN of data terminal equipment with V-Series typeinterfaces with provision for statistical multiplexing, Rec. V.120.
CCITT Recommendation Pulse code modulation (PCM) of voice frequencies, Rec. G.711.
CCITT Recommendation 32 kbit/s adaptive differential pulse code modulation (ADPCM),
Rec. G.721.
CCITT Recommendation 7 kHz audio coding within 64 kbit/s, Rec. G.722.
CCITT Recommendation Codec for audiovisual services AT n ¥ 384 kbit/s, Rec. H.261.
CCITT Recommendation Support of packet mode terminal equipment by an ISDN, Rec.
X.31.
CCITT Recommendation Multiplexing rate adaption and support of existing interfaces, Rec.
I.460.

B-IF2.02-01-TS

[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]

[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]

[39]
[40]

CCITT Recommendation Standardization of data signalling rates for synchronous datatransmission on leased telephone-type circuits, Rec. V.6.
CCITT Recommendation International user classes of service in public data networks andintegrated services digital networks (ISDNs), Rec. X.1.
CCITT Recommendation ISDN numbering and addressing principles, Rec. I.330.
CCITT Recommendation Numbering plan for the ISDN era, Rec. E.164.
CCITT Recommendation Numbering plan for the international telephone service, Rec.
E.163.
CCITT Recommendation International numbering plan for public data networks, Rec.
X.121.
CCITT Recommendation Plan for telex destination codes, Rec. F.69.
CCITT Recommendation Network service definition for Open Systems Interconnection(OSI) for CCITT applications, Rec. X.213.
ISO 8348:1987/Add.2:1988 Information processing systems – Data communications –Network service definition – Addendum 2: Network layer addressing.
CCITT Recommendation Principles relating ISDN numbers/subaddress to the OSI reference
model network layer addresses, Rec. I.334.
CCITT Recommendation Interface between data terminal equipment (DTE) and data
circuit-terminating equipment (DCE) for synchronous operation on public data networks,
Rec. X.21.
CCITT Recommendation Primary rate user-network interface – Layer 1 specification, Rec.
I.431.
CCITT Recommendation Control procedures for teletex and Group 4 facsimile services,Rec. T.62.
CCITT Recommendation A document application profile for the interchange of Group 4
facsimile documents, Rec. T.503.
CCITT Recommendation A document application profile MM for the interchange offormatted mixed mode documents, Rec. T.501.
CCITT Recommendation Document application profile PM1 for the interchange ofprocessable form documents, Rec. T.502.
CCITT Recommendation Network-independent basic transport service for the telematic
services, Rec. T.70.
CCITT Recommendation Document application profile for videotex interworking, Rec.
T.504.
CCITT Recommendation Teleservices supported by an ISDN, Rec. I.241.
CCITT Recommendation System aspects of the use of the 7 kHz audio codec
within 64 kbit/s, Rec. G.725.
ISO 1745:1975 Information processing – Basic mode control procedures for data
communication systems.
CCITT Recommendation Link access protocol balanced (LAPB) extended for half-duplex
physical level facility, Rec. T.71.
ISO/IEC 4335:1991 Information technology – Telecommunications and informationexchange between systems – High-level data link control (HDLC) procedures – Elements ofprocedures.
ISO 8802-2:1989 Information processing systems – Local area networks – Part 2: Logicallink control.
CCITT Recommendation Packet switched signalling system between public networks
providing data transmission services, Rec. X.75.

B-IF2.02-01-TS

223

[41]
[42]
[43]
[44]
[45]
[46]
[47]
[48]
[49]
[50]
[51]
[52]
[53]
[54]
[55]
[56]

[57]

[58]
[59]
[60]
[61]

[62]
[63]
[64]
[65]

224

ISO/IEC 8208:1990 Information technology – Data communications – X.25 Packet layer
Protocol for data terminal equipment.
ISO 8348:1987 Information processing systems – Data communications – Network service
definition.
ISO 8473:1988 Information processing systems – Data communications – Protocol for
providing the connectionless-mode network service.
CCITT Recommendation Procedure for the exchange of protocol identification during
virtual call establishment on packet switched public data networks, Rec. X.244.
CCITT Recommendation ISDN user-network interface data link layer – General aspects,
Rec. Q.920/I.440.
CCITT Recommendation Basic user-network interface – Layer 1 specification, Rec. I.430.
CCITT Recommendation Definition of bearer service categories, Rec. I.230.
CCITT Recommendation Definition of teleservices, Rec. I.240.
CCITT Recommendation International Alphabet No. 5, Rec. T.50.
ISO 646 Information processing – ISO 7-bit coded character set for informationinterchange.
CCITT Recommendations on Integrated services digital network (ISDN).
CCITT Recommendation Support of data terminal equipments (DTEs) with V-Series typeinterfaces by an integrated services digital network (ISDN), Rec. I.463.
CCITT Recommendation, Blue Book Vol. VI, Rec. Q.931 (1988).
CCITT Recommendation Stage 3 description for additional information transfer
supplementary services using DSS1, Rec. Q.957.
CCITT Recommendation 300 bits per second duplex modem standardized for use in thegeneral switched telephone network, Rec. V.21.
CCITT Recommendation 1200 bits per second duplex modem standardized for use in thegeneral switched telephone network and on point-to-point 2-wire leased telephone-type
circuits, Rec. V.22.
CCITT Recommendation 2400 bits per second duplex modem using frequency division
technique standardized for use in the general switched telephone network and on point-topoint 2-wire leased telephone-type circuits, Rec. V.22 bis.
CCITT Recommendation 600/1200-baud modem standardized for use in the generalswitched telephone network, Rec. V.23.
CCITT Recommendation 2400 bits per second modem standardized for use on 4-wire leased
telephone-type circuits, Rec. V.26.
CCITT Recommendation 2400/1200 bits per second modem standardized for use in thegeneral switched telephone network, Rec. V.26 bis.
CCITT Recommendation 2400 bits per second duplex modem using the echo cancellation
technique standardized for use on the general switched telephone network and on point-topoint 2-wire leased telephone type circuits, Rec. V.26 ter.
CCITT Recommendation 4800 bits per second modem with manual equalizer standardized
for use on leased telephone-type circuits, Rec. V.27.
CCITT Recommendation 4800/2400 bits per second modem with automatic equalizer
standardized for use on leased telephone-type circuits, Rec. V.27 bis.
CCITT Recommendation 4800/2400 bits per second modem standardized for use in thegeneral switched telephone network, Rec. V.27 ter.
CCITT Recommendation 9600 bits per second modem standardized for use on point-topoint 4-wire leased telephone-type circuits, Rec. V.29.

B-IF2.02-01-TS

[66]

[67]
[68]

[69]

[70]
[71]
[72]
[73]
[74]
[75]
[76]
[77]
[78]
[79]
[80]
[81]

[82]
[83]
[84]
[85]
[86]

CCITT Recommendation A family of 2-wire, duplex modems operating at data signallingrates of up to 9600 bit/s for use on the general switched telephone network and on leased
telephone-type circuits, Rec. V.32.
CCITT Recommendation Usage of cause and location in the digital subscriber signallingsystem No. 1 and the signalling system No. 7 ISDN user part, Rec. Q.850.
CCITT Recommendation Operational provisions for the international public facsimile
service between subscribers stations with group 3 facsimile machines (telefax 3), Rec.
F.182.
CCITT Recommendation Operational provisions for the international public facsimile
service between subscribers stations with group 4 facsimile machines (telefax 4), Rec.
F.184.
CCITT Recommendation Service requirements unique to mixed mode (MM) used within theteletex service, Rec. F.230.
CCITT Recommendation Service requirements unique to the processable mode number one(PM1) used within the teletex service, Rec. F.220.
CCITT Recommendation Teletex service, Rec. F.200.
CCITT Recommendation Videotex service, Rec. F.300.
CCITT Recommendation Syntax-Based videotex end-to-end protocols for the circuitmode ISDN, Rec. T.102.
CCITT Recommendation International interworking for videotex services, Rec. T.101.
CCITT Recommendation Operational provisions for the international telex service, Rec.
F.60.
CCITT Recommendation Data communication networks: Message handling systems (MHS),
Recs. X.400-Series.
CCITT Recommendation Open systems interconnection (OSI): Model and notation, service
definition, Recs. X.200-Series.
CCITT Recommendation Videotelephony teleservice for ISDN, Rec. F.721.
CCITT Recommendation Audiographic services, Recs. F.700-Series.
ISO/IEC 8878:1992 Information technology – Telecommunications and informationexchange between systems – Use of X.25 to provide the OSI connection-mode Network
Service.
ISO/IEC TR9577: 1990 Information technology-Telecommunications and informationexchange b between systems-Protocol identification in the network layer.
CCITT Recommendation Stage 3 description for supplementary services using DSSI, Recs.
Q.950-Series.
CCITT Recommendation Stage 3 description for call completion supplementary services
using DSSI, Rec. Q.953.
CCITT Recommendation Stage 3 description for number identification supplementary
services using DSSI, Rec. Q951.
CCITT Recommendation Stage 3 description for call offering supplementary service using
DSSI, Rec. Q. 952.

B-IF2.02-01-TS

225