home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-12 | 80.6 KB | 3,402 lines |
- .rs
- .\" Troff code generated by TPS Convert from ITU Original Files
- .\" Not Copyright ( c) 1991
- .\"
- .\" Assumes tbl, eqn, MS macros, and lots of luck.
- .TA 1c 2c 3c 4c 5c 6c 7c 8c
- .ds CH
- .ds CF
- .EQ
- delim @@
- .EN
- .nr LL 40.5P
- .nr ll 40.5P
- .nr HM 3P
- .nr FM 6P
- .nr PO 4P
- .nr PD 9p
- .po 4P
-
- .rs
- \v | 5i'
- .sp 1P
- .ce 1000
- \v'12P'
- \s12PART\ V
- \v'4P'
- .RT
- .ce 0
- .sp 1P
- .ce 1000
- \fBI.500\(hySeries Recommendations\fR \v'2P'
- .ce 0
- .sp 1P
- .ce 1000
- \fBINTERNETWORK\ INTERFACES\fR
- .ce 0
- .sp 1P
- .LP
- .rs
- .sp 31P
- .ad r
- Blanc
- .ad b
- .RT
- .LP
- .bp
- .LP
- \fBMONTAGE: PAGE 2 = PAGE BLANCHE\fR
- .sp 1P
- .RT
- .LP
- .EF '% Fascicle\ III.9\ \(em\ Rec.\ I.500''
- .OF '''Fascicle\ III.9\ \(em\ Rec.\ I.500 %'
- .LP
- .bp
- .sp 2P
- .LP
- \fBRecommendation\ I.500\fR
- .RT
- .sp 2P
- .sp 1P
- .ce 1000
- \fBGENERAL\ STRUCTURE\ OF\ THE\ ISDN\ INTERWORKING\ RECOMMENDATIONS\fR
- .EF '% Fascicle\ III.9\ \(em\ Rec.\ I.500''
- .OF '''Fascicle\ III.9\ \(em\ Rec.\ I.500 %'
- .ce 0
- .sp 1P
- .ce 1000
- \fI(Melbourne, 1988)\fR
- .sp 9p
- .RT
- .ce 0
- .sp 1P
- .LP
- \fB1\fR \fBIntroduction\fR
- .sp 1P
- .RT
- .PP
- An ISDN is a network, in general evolving from a telephony
- Integrated Digital Network, that provides end\(hyto\(hyend digital connectivity
- to
- support a wide range of services, including voice and non\(hyvoice services, to
- which users have access by a limited set of standard multi\(hypurpose user
- network interfaces. In contrast, existing dedicated networks have always
- been developed for specific (types of) services. Therefore, especially
- in the initial phase, the ISDN may support many services which in principle
- are still existent in
- dedicated networks. Thus, it is necessary to provide interworking between
- ISDN and dedicated networks to allow communication between terminals belonging
- to equivalent services offered through different networks.
- .PP
- There will be a need for interworking functions (IWF) between ISDN and
- dedicated networks to cope with the different environments given by the
- various networks. The structure of these IWFs showing the functions necessary
- for the mapping should be uniform to permit, if possible, a common use
- of
- functional parts in several IWFs. Detailed description of these IWFs, which
- (as far as is possible), should permit conveyance of ISDN features through
- existing networks, is given in the I.500\(hySeries of Recommendations.
- .PP
- The I.500\(hySeries of Recommendations deal with network aspects of
- interworking.
- .RT
- .sp 2P
- .LP
- \fB2\fR \fBOrganization of ISDN interworking Recommendations\fR
- .sp 1P
- .RT
- .PP
- Figure\ 1/I.500 shows the organization of the ISDN interworking
- Recommendations contained in the I.500\(hySeries Recommendations, and the
- relationship with other Recommendations. The Recommendations in Figure\
- 1/I.500 have been grouped by level of detail into:
- .RT
- .LP
- \(em
- general level;
- .LP
- \(em
- scenario level;
- .LP
- \(em
- functional level;
- .LP
- \(em
- protocol level.
- .sp 1P
- .LP
- 2.1
- \fIGeneral level\fR
- .sp 9p
- .RT
- .PP
- Recommendations I.500 and I.510 form the general level, i.e., the basis
- for Recommendations in the scenario and functional levels.
- .PP
- Recommendation I.500 describes the organization of the (ISDN
- interworking) Recommendations and the structure of the I.500\(hySeries of
- Recommendations, whilst I.510 sets out the ISDN interworking
- principles.
- .RT
- .sp 1P
- .LP
- 2.2
- \fIScenario level\fR
- .sp 9p
- .RT
- .PP
- The scenario level of Recommendations describes the general
- arrangements for interworking between ISDN and ISDN, and between ISDN and
- dedicated networks. Recommendation\ I.515 specifying the parameter exchange
- which may be necessary for interworking situations, is also located at the
- scenario level.
- .RT
- .sp 1P
- .LP
- 2.3
- \fIFunctional level\fR
- .sp 9p
- .RT
- .PP
- The detailed level is formed by those Recommendations that are
- specifying the interworking functional requirements of the interworking
- scenarios shown in the scenario level Recommendations.
- .RT
- .sp 1P
- .LP
- 2.4
- \fIProtocol level\fR
- .sp 9p
- .RT
- .PP
- In the protocol level, the protocols listed are those that appear at the
- reference points K\dx\uand\ N\dx\u.
- .PP
- \fINote\fR \ \(em\ ISDN interworking related subjects that correspond to the
- above four levels are also dealt with in the Recommendations\ I.310, I.324,
- I.340, X.300 and\ X.301. Recommendation\ I.310 defines the interworking
- reference points and an outline description of IWF.
- .bp
- .PP
- Recommendation I.340 defines ISDN Connection Types.
- .PP
- Recommendations\ X.300 and X.301 give the guiding principles and
- functions for interworking between networks offering data services described
- in Recommendations\ X.1 and\ X.10.
- .RT
- .PP
- 2.5
- Recommendations which relate to interworking are shown in
- Figure\ 1/I.500 and are assigned to the levels listed in \(sc\ 2. As the
- contents of some Recommendations cover more than one level, these Recommendations
- appear at each level to which they relate.
- .sp 9p
- .RT
- .LP
- .rs
- .sp 30P
- .ad r
- \fBFigure 1/I.500, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 2P
- .LP
- \fB3\fR \fBReferences\fR
- .sp 1P
- .RT
- .PP
- The references are general to all I.500 Recommendations and are to be read
- in conjunction with Figure\ 1/I.500, where the organization of ISDN
- interworking Recommendations is shown.
- .RT
- .sp 1P
- .LP
- 3.1
- \fIInterworking\fR
- .sp 9p
- .RT
- .PP
- X.300\(hySeries
- Interworking between public networks, and
- between public networks and other networks for the provision
- of data transmission services
- .RT
- .LP
- I.324
- ISDN architecture functional model
- .LP
- I.340
- Connection types/elements for ISDN\(hyISDN
- interworking
- .LP
- X.31
- Support of packet\(hymode terminal equipment by
- an ISDN
- .LP
- X.81
- Interworking between an ISDN circuit switched and a
- circuit switched public data network
- (CSPDN)
- .bp
- .sp 1P
- .LP
- 3.2
- \fIServices and network capabilities\fR
- .sp 9p
- .RT
- .PP
- X.1
- International user classes of service in public data
- networks and integrated services digital networks
- (ISDNs)
- .RT
- .LP
- X.2
- International data transmission services and
- optional user facilities in public data networks
- and ISDNs
- .LP
- X.10
- Categories of access for data terminal equipment
- (DTE) to public data transmission services
- .LP
- I.122
- Framework for providing additional packet\(hymode
- bearer services
- .LP
- I.200\(hySeries
- Service aspects supported by an ISDN
- .LP
- I.310
- ISDN \(em Network functional principles
- .LP
- I.320
- ISDN protocol reference model
- .LP
- I.325
- Reference configurations for ISDN connection types
- .LP
- I.411
- ISDN user\(hynetwork interfaces \(em reference
- configurations
- .LP
- I.412
- ISDN user\(hynetwork interfaces \(em
- Interface structures and access capabilities
- .LP
- I.420
- Basic rate user\(hynetwork interface
- .LP
- I.421
- Primary rate user\(hynetwork interface
- .LP
- I.441
- .LP
- (Q.921)
- \-v'10p'
- ISDN user\(hynetwork interface data link
- layer specification
- \v'10p'
- .LP
- I.451
- .LP
- (Q.931)
- \-v'10p'
- ISDN user\(hynetwork interface
- layer\ 3 specification
- \v'10p'
- .sp 1P
- .LP
- 3.3
- \fISignalling\fR
- .sp 9p
- .RT
- .PP
- Q.700
- Network protocols (MTP, ISUP, etc.)
- .RT
- .LP
- Q.120\(hyQ.180
- Specification of Signalling Systems No.\ 4
- and No.\ 5
- .LP
- Q.251\(hyQ.300
- Specification of Signalling System No.\ 6
- .LP
- Q.310\(hyQ.490
- Specification of Signalling Systems R1
- and R2
- .LP
- X.25
- Interface between data terminal equipment (DTE) and
- data circuit equipment (DCE) for terminals operating in
- the packet\(hymode and connected to public data networks
- by dedicated circuits
- .LP
- X.71
- Decentralized terminal and transit control signalling
- system on international circuits between synchronous
- data networks
- .LP
- X.75
- Packet switched signalling system between public
- networks providing data transmission
- services
- .LP
- U.12
- Terminal and transit control signalling system for telex
- and similar services on international circuits (type\ D
- signalling)
- .sp 1P
- .LP
- 3.4
- \fIRate adaptation\fR
- .sp 9p
- .RT
- .PP
- I.460
- Multiplexing, rate adaptation and support of existing
- interfaces
- .RT
- .LP
- I.461
- .LP
- (X.30)
- \-v'10p'
- Support of X.21, X.21 | fIbis\fR | and
- X.20 | fIbis\fR | based DTEs by an ISDN
- \v'10p'
- .LP
- I.462
- .LP
- (X.31)
- \-v'10p'
- Support of packet\(hymode terminal
- equipment by an ISDN
- \v'10p'
- .LP
- I.463
- .LP
- (V.110)
- \-v'10p'
- Support of DTEs with V\(hySeries
- type interfaces by an ISDN
- \v'10p'
- .LP
- I.464
- Multiplexing, rate adaptation and support of
- existing interfaces for restricted 64\ kbit/s
- transfer capability
- .LP
- I.465
- .LP
- (V.120)
- \-v'10p'
- Support by ISDN of DTEs with V\(hySeries
- type interfaces with provision for statistical
- multiplexing
- .bp
- .sp 1P
- .LP
- 3.5
- \fINumbering\fR
- .sp 9p
- .RT
- .PP
- X.121
- International numbering plan for public data
- networks
- .RT
- .LP
- X.122
- Numbering plan interworking between a Packet Switched
- Public Data Network (PSPDN) and an Integrated Services
- Digital Network (ISDN) or Public Switched Telephone Network
- (PSTN) in the short\(hyterm
- .LP
- I.331
- .LP
- (E.164)
- \-v'10p'
- Numbering plan for the ISDN era
- \v'10p'
- .LP
- E.166
- Numbering plan interworking in the ISDN era
- .LP
- I.330
- ISDN numbering and addressing principles
- .LP
- I.332
- Numbering principles for interworking between
- ISDNs and dedicated networks with different numbering
- plans
- .LP
- F.69
- Plan for telex destination codes
- .sp 2P
- .LP
- \fBRecommendation\ I.510\fR
- .RT
- .sp 2P
- .sp 1P
- .ce 1000
- \fBDEFINITIONS\ AND\ GENERAL\ PRINCIPLES\ FOR\ ISDN\ INTERWORKING\fR
- .EF '% Fascicle\ III.9\ \(em\ Rec.\ I.510''
- .OF '''Fascicle\ III.9\ \(em\ Rec.\ I.510 %'
- .ce 0
- .sp 1P
- .ce 1000
- \fI(Melbourne, 1988)\fR
- .sp 9p
- .RT
- .ce 0
- .sp 1P
- .LP
- \fB1\fR \fBIntroduction\fR
- .sp 1P
- .RT
- .PP
- This Recommendation sets forth the general principles for
- interworking between ISDNs, between ISDNs and other networks, and internal
- to an ISDN. The need for interworking stems from the coexistence of existing
- dedicated networks with ISDNs and from the use of different, yet compatible,
- bearer services or teleservices for the provision of an end\(hyto\(hyend
- telecommunication service. When ISDNs are introduced, it is to be expected
- that most users will need to interwork with the users of other networks,
- especially public switched telephone networks (PSTNs), public land mobile
- networks (PLMNs) and dedicated data networks.
- .PP
- Normally, each instance of communication within an ISDN will take
- place between the users of services with identical attribute values. However,
- communication may also take place between users of services with non\(hyidentical
- attribute values. In these cases interworking functions (IWFs) will be
- required. In general, when an ISDN user communicates with the user of another
- network, if the service perceived by the user of that other network were
- to be defined by the attribute method, the values would not be identical
- to those of the ISDN user.
- .PP
- The purpose of interworking is to enable the users of \*Qdifferent\*U
- services on an ISDN to establish a useful communication or for an ISDN
- user to establish a useful communication with a user of another network
- and vice\(hyversa. The term \*Qservice\*U in this Recommendation implies
- a telecommunication service as defined in Recommendation\ I.210.
- .PP
- To permit interworking, interworking capabilities, making use of
- IWFs, may be required in one or more of the following:
- .RT
- .LP
- \(em
- the ISDN,
- .LP
- \(em
- any other network involved,
- .LP
- \(em
- customer equipment.
- .sp 2P
- .LP
- \fB2\fR \fBScope\fR
- .sp 1P
- .RT
- .PP
- This Recommendation contains the definitions and general principles to
- be applied in instances of ISDN interworking, which include interworking
- between ISDNs, between ISDNs and other networks, and internal to
- an\ ISDN.
- .bp
- .PP
- The ISDN interworking configurations to be considered within the scope
- of this Recommendation include the interconnection of two networks where
- at
- least one network is an ISDN, the concatenation of more than two networks
- where an ISDN interconnects other networks (as a transit network), or the
- interconnection of two ISDNs by one or more other networks.
- .PP
- ISDN interworking, as defined in this Recommendation, is
- considered to take place whenever end\(hyto\(hyend communication has to be
- provided:
- .RT
- .LP
- a)
- between different networks where at least one network
- is an ISDN, or
- .LP
- b)
- between telecommunication services with different lower or
- higher layer attributes or both, where at least one of the
- interworking telecommunication service is supported by the
- ISDN, or
- .LP
- c)
- between different networks and between telecommunication
- services with different lower or higher layer service
- attributes, or both.
- .PP
- ISDN interworking, as defined in this Recommendation, is intended to cover
- both voice and non\(hyvoice applications.
- .PP
- \fINote\fR \ \(em\ Interworking at layers above layer\ 3 of the OSI model
- is not generally specified within this Recommendation and is for further
- study.
- .RT
- .sp 2P
- .LP
- \fB3\fR \fBAbbreviations\fR
- .sp 1P
- .RT
- .PP
- CCSN
- Common channel signalling network
- (SS\ No.7)
- .RT
- .LP
- CE
- Connection element
- .LP
- CS
- Circuit switched
- .LP
- CSPDN
- Circuit switched public data network
- .LP
- DTE
- Data terminal equipment
- .LP
- ISDN
- Integrated Services Digital Network
- .LP
- IWF
- Interworking function
- .LP
- OSI
- Open Systems Interconnection
- .LP
- PDN
- Public data network
- .LP
- PH
- Packet handler
- .LP
- PLMN
- Public land mobile network
- .LP
- PS
- Packet switched
- .LP
- PSPDN
- Packet switched public data network
- .LP
- PSTN
- Public switched telephone network
- .LP
- SS\ No.7
- Signalling System No.\ 7
- .LP
- TA
- Terminal adaptor
- .LP
- TE
- Terminal equipment
- .sp 2P
- .LP
- \fB4\fR \fBDefinitions\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 4.1
- \fIDefinitions related to services and network capabilities\fR
- .sp 9p
- .RT
- .PP
- The definitions which follow are related to services and to
- network capabilities. In those instances where terms already are
- defined in other Recommendations, appropriate references are made to such
- Recommendations.
- .PP
- The following definitions apply to ISDN interworking:
- .PP
- \fITelecommunication service\fR , as defined in Recommendation I.210.
- .PP
- \fIBearer service in the ISDN\fR , as defined in Recommendation I.210 and
- in the I.230\(hySeries.
- .PP
- \fITeleservice\fR , as defined in Recommendation\ I.210 and in the
- I.240\(hySeries, provides the full capacity for communication through
- terminal and network lower and higher layer functions.
- .PP
- \fIBearer service in dedicated networks:\fR | The term \fIbearer service\fR
- | in dedicated networks is characterized by a set of lower layer attributes
- (e.g.\ data transmission services, as defined in Recommendation\ X.1, for
- use in public data networks) and corresponds to the term \fIbearer service\fR
- in an ISDN. Examples of \fIbearer services\fR in dedicated networks are
- data transmission over a data network and data transmission over the telephone
- network.
- .bp
- .PP
- \fISupplementary service\fR , as defined in Recommendation I.210 and in
- the I.250 Series.
- .PP
- \fIBearer capability\fR , as defined in Recommendation I.210, specifies
- the technical features of a \fIbearer service\fR in an ISDN as these appear
- to a user at the access point (S/T\ reference point). The term \fIbearer
- capability\fR also
- may be used with respect to dedicated networks. A \fIbearer capability\fR
- does not include any terminal functions.
- .RT
- .sp 1P
- .LP
- 4.2
- \fIDefinitions related to general ISDN interworking configurations\fR
- .sp 9p
- .RT
- .PP
- This section provides concepts and definitions of terms relevant to the
- general ISDN interworking configuration. Figure\ 1/I.510 depicts the scope
- of application of several key terms.
- .RT
- .LP
- .rs
- .sp 25P
- .ad r
- \fBFigure 1/I.510, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- In accordance with Figure 1/I.510, the following terms are
- defined:
- .sp 1P
- .LP
- \fBinterworking\fR
- .sp 9p
- .RT
- .PP
- Within the scope of the I.500\(hySeries of Recommendations, the term \fIinterworking\fR
- | is used to express interactions between networks, between end systems,
- or between parts thereof, with the aim of providing a functional
- entity capable of supporting an end\(hyto\(hyend communication. The interactions
- required to provide a functional entity rely on functions and on the means
- to select these functions.
- .RT
- .sp 1P
- .LP
- \fBinterworking functions (IWFs)\fR
- .sp 9p
- .RT
- .PP
- The functions referred to in the Interworking definition above,
- which include the conversion of physical and electrical states and the
- mapping of protocols. An IWF may be implemented in the ISDN, in the other
- network(s), at the user's premises, through a third\(hyparty service provider,
- or in some
- combination of these.
- .bp
- .PP
- The IWFs needed as a result of a service requirement for
- interworking are categorized as
- connection\(hydependent IWFs
- or
- communication\(hydependent IWFs
- . The relationships among these
- terms and definitions for connection\(hydependent IWFs and for
- communication\(hydependent IWFs are contained in
- Figure\ 2/I.510.
- .RT
- .LP
- .rs
- .sp 25P
- .ad r
- \fBFigure 2/I.510, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 2P
- .LP
- \fB5\fR \fBTelecommunication services to be supported by ISDN\fR
- \fBinterworking configurations\fR
- .sp 1P
- .RT
- .PP
- This section contains a list of telecommunication services that are supported
- by interconnections between ISDNs and between ISDNs and other
- networks and defines the types of interworking functions required.
- The concept of \(sc\ 5 take into account:
- .RT
- .LP
- a)
- the definitions as outlined in \(sc\ 4;
- .LP
- b)
- existing networks to be interconnected with ISDN
- (ISDNs, PSTNs, CSPDNs, PSPDNs, others);
- .LP
- c)
- services to be offered with the ISDN and through
- interworking with ISDN.
- .PP
- End\(hyto\(hyend communication
- may require:
- .LP
- i)
- interworking at lower layers;
- .LP
- ii)
- interworking at higher layers;
- .LP
- iii)
- interworking at both lower and higher
- layers.
- .PP
- Table 1/I.510 displays the networks that support telecommunication services
- which are also supported by an ISDN and which are candidates,
- therefore, for interworking with an ISDN in the provision of one of those
- telecommunication services. Furthermore, Table\ 1/I.510 depicts the type of
- interworking functions that may be required for each interworking
- configuration. Note that the table does not indicate the possibility for
- interworking between different telecommunication services
- (e.g.\ telex\(hyto\(hyTeletex).
- .bp
- .ce
- \fBH.T. [T1.510]\fR
- .ce
- TABLE\ 1/I.510
- .ce
- \fBNetwork support of telecommunication services\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- cw(90p) | cw(18p) sw(18p) sw(18p) sw(18p) sw(18p) sw(48p) , ^ | c | c | c | c | c | c.
- {
- Telecommunication services
- supported by the ISDN
- } ISDN interconnected with
- ISDN PSTN CSPDN PSPDN Telex Other dedicated networks
- _
- .T&
- lw(90p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) .
- Telephony 0 N \(em \(em \(em N
- _
- .T&
- lw(90p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) .
- {
- Data transmission (see Note 2)
- } (L) N, | N, | L) N, | L) \(em N, | L)
- _
- .T&
- lw(90p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) .
- Telex 0 \(em \(em \(em N, | N, |
- _
- .T&
- lw(90p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) .
- Teletex 0 N, | N, | N, | \(em N, | , |
- _
- .T&
- lw(90p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) .
- Fascimile 0 N, | N, | N, | \(em N, |
- .TE
- .LP
- 0
- No interworking functions foreseen
- .LP
- N
- Connection\(hydependent interworking needed
- .LP
- L
- Lower layer communication\(hydependent interworking
- needed
- .LP
- H
- Higher layer communication\(hydependent interworking
- needed
- .LP
- (\ )
- N/L/H may be needed
- .LP
- \fINote\ 1\fR
- \ \(em\ The list of services in Table 1/I.510 is not
- exhaustive and is therefore for further study. In particular,
- bearer services must be included.
- .LP
- \fINote\ 2\fR
- \ \(em\ See Recommendation X.1 for a description of data
- transmission services.
- .LP
- \fINote\ 3\fR
- \ \(em\ It is assumed for Table 1/I.510 that, for the cases
- of ISDN\(hyto\(hyISDN interworking, the telecommunication services
- listed above are supported in both ISDNs by the same bearer,
- no interworking functions are therefore required. ISDN\(hyto\(hyISDN
- interworking situations that involve different bearers, as
- an extension of Table\ 1/I.510, are for further
- study.
- .nr PS 9
- .RT
- .ad r
- \fBTableau 1/I.510 [T1.510], p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .sp 1
- .sp 2P
- .LP
- \fB6\fR \fBISDN interworking configurations\fR
- .sp 1P
- .RT
- .PP
- This section contains the general interworking reference
- configurations that form the basis of all possible ISDN interworking
- configurations covered by the I.500\(hySeries of Recommendations.
- .PP
- The configurations are entirely functional and do not serve any aspect
- of the interworking function(s) needed in any specific instance of
- interworking. The complexities of specific cases are considered in the
- Recommendations that deal at a scenario level of detail with the individual
- types of networks with which an ISDN may be interconnected,
- i.e.\ Recommendations\ I.520, I.530,\ etc.
- .PP
- The network interworking reference point is the K\dx\uor \dx\ureference
- point when the network directly interconnected to the ISDN is a
- non\(hyISDN or an ISDN, respectively.
- .RT
- .sp 1P
- .LP
- 6.1
- \fIReference points for network interconnections\fR
- .sp 9p
- .RT
- .PP
- The protocol reference model for ISDN interworking is outlined in \(sc\
- 5 of Recommendation\ I.320.
- .PP
- The reference points K\dx\uand N\dx\ufor network interconnections are defined
- in Recommendation\ I.324, \(sc\ 4.2.4.
- .bp
- .PP
- According to Note 1 to Figure\ 8/I.324 the value x\ =\ 1 signifies that
- interworking functions exist in the ISDN. The value x\ =\ 2 signifies that
- no
- interworking functions are required in the ISDN. No assumption is made
- regarding interworking functions outside the ISDN. Regardless of the value
- of x, the possibility of interworking functions in the other networks,
- between the networks, or of some combination of these situations, is kept
- open. The case of N\d1\ucovers the situation when interworking functions
- are split between the
- two ISDNs involved.
- .RT
- .sp 1P
- .LP
- 6.1.1
- \fIInterworking using one\(hystage selection (one\(hystage\fR
- \fIinterworking)\fR
- .sp 9p
- .RT
- .PP
- Interworking using one\(hystage selection is possible when the
- interconnection of networks takes place by interconnecting trunk lines.
- It is also possible when the networks are physically inseparable [for example,
- see
- b) of Figure\ 6/I.510, and associated text]. In this type of interworking,
- each of the terminals involved in a communication has assigned to it a
- directory
- number from the numbering plan of the network to which it is connected. For
- call establishment, one\(hystage selection is assumed. An example of this
- type of interworking is the interconnection of a CSPDN using X.71 interexchange
- signalling and an ISDN using SS\ No.\ 7 interexchange signalling.
- .PP
- For interworking by one\(hystage selection, the interconnection of
- networks takes place at reference points K\dx\uor \dx\u(see
- Figure\ 3/I.510).
- .PP
- The application of existing interfaces and the specification of new
- interfaces at the K\dx\uand N\dx\ureference points for interworking by
- one\(hystage selection needs further study.
- .PP
- \fINote\fR \ \(em\ In Recommendation X.300 this category of interworking is
- defined as \*Qinterworking by call control mapping\*U (see \(sc\ 6.2.1 of
- Recommendation\ X.300).
- .RT
- .LP
- .rs
- .sp 9P
- .ad r
- \fBFigure 3/I.510, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- 6.1.2
- \fIInterworking using two\(hystage selection\fR \fI(two\(hystage\fR
- \fIinterworking)\fR
- .sp 9p
- .RT
- .PP
- Interworking using two\(hystage selection is sometimes required,
- e.g.\ access to a PSPDN through an ISDN according to case\ A of
- Recommendation\ X.31. In this example, each of the terminals involved in a
- communication has assigned to it a directory number from the numbering
- plan of the PSPDN. For call establishment, two\(hystage selection is assumed:
- first, a
- connection is established through the ISDN to the appropriate PSPDN port;
- second, a connection is established through the PSPDN to the called
- terminal.
- .PP
- The logical appearance of interworking by two\(hystage selection at
- reference point\ K\d2\u(see Note\ 1) may be that of a customer access (see
- Figure\ 4/I.510).
- .PP
- The application of existing interfaces and the specification of
- new interfaces at the K\d2\u\ reference point for interworking by two\(hystage
- selection is for further study.
- .PP
- \fINote\ 1\fR \ \(em\ Since, in the case of interworking using two\(hystage
- selection depicted in Figure\ 4/I.510, no IWFs are required in the ISDN, only
- reference point\ K\d2\uis relevant.
- .PP
- \fINote\ 2\fR \ \(em\ In Recommendation X.300, examples of this category of
- interworking are defined as \*Qinterworking by port access\*U (see \(sc\
- 6.2.2 of
- Recommendation\ X.300).
- .bp
- .RT
- .LP
- .rs
- .sp 9P
- .ad r
- \fBFigure 4/I.510, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 2P
- .LP
- 6.2
- \fIISDN\(hyto\(hyISDN interconnection\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 6.2.1
- \fIReference configuration\fR
- .sp 9p
- .RT
- .PP
- With regard to ISDN\(hyto\(hyISDN interworking in the context of the
- I.500\(hySeries of Recommendations, the functionality required for bearer
- service interworking is contained in ISDN\(hyto\(hyISDN internetwork interfaces.
- .PP
- Figure\
- 5/I.510 shows a reference configuration for ISDN\(hyto\(hyISDN
- interworking. The services offered at the endpoints may be different.
- .PP
- ISDN\(hyto\(hyISDN interworking may involve the functionality required
- for interworking to take place between ISDNs operated by, for instance,
- different Administrations.
- .RT
- .LP
- .rs
- .sp 14P
- .ad r
- \fBFigure 5/I.510, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- 6.2.2
- \fIConnection types\fR
- .sp 9p
- .RT
- .PP
- Applicable Recommendation: I.520.
- .RT
- .LP
- a)
- ISDN circuit mode | (hy | SDN circuit mode (both ISDNs supporting
- a circuit\(hyswitched bearer service);
- .LP
- b)
- ISDN packet mode | (hy | SDN packet mode (both ISDNs supporting
- the ISDN virtual circuit bearer service defined in
- Recommendation\ X.31 under case\ b);
- .LP
- c)
- ISDN packet mode | (hy | SDN circuit mode (interworking where
- a packet switched bearer is requested by one ISDN and a
- circuit switched bearer by the other ISDN);
- .LP
- d)
- ISDN packet mode | (hy | SDN circuit mode (interworking,
- where a circuit switched bearer is requested in one ISDN
- to obtain access to the packet handler of another ISDN for
- communication over an ISDN virtual circuit bearer
- service).
- .bp
- .sp 2P
- .LP
- 6.3
- \fIInterworking between ISDNs and other networks\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 6.3.1
- \fIReference configurations\fR
- .sp 9p
- .RT
- .PP
- Network interworking is required whenever an ISDN and a non\(hyISDN
- are interconnected to provide an end\(hyto\(hyend connection.
- .PP
- Network interworking functions typically would contain the
- functionality needed for conversion of physical and electrical interface
- characteristics and for mapping of layer\ 2 and layer\ 3 network protocols.
- Examples of such network interworking functions are: signalling conversions,
- information transfer, protocol conversions, analogue\(hyto\(hydigital (and
- \fIvice\fR
- \fIversa\fR ) conversions, and interworking between different numbering
- and charging plans.
- .PP
- Two reference configurations for network interworking are shown
- in Figure\ 6/I.510. The services offered at the endpoints may be
- different.
- .PP
- The separation between an ISDN and a non\(hyISDN may not always be
- obvious. A local exchange may, for example, support both traditional telephony
- service and ISDN services. The physical network components supporting these
- services may be inseparable. From a functional perspective, such a case
- might be covered by a) of Figure\ 6/I.510, while b) of Figure\ 6/I.510
- might be more
- appropriate from an implementation point of view.
- .RT
- .LP
- .rs
- .sp 16P
- .ad r
- \fBFigure 6/I.510, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 2P
- .LP
- 6.3.2
- \fIConnection types\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 6.3.2.1
- \fIISDN\(hyPSTN\fR
- .sp 9p
- .RT
- .PP
- Applicable Recommendation: I.530.
- .RT
- .LP
- a)
- ISDN circuit mode\(hyPSTN
- .LP
- \(em
- speech
- .LP
- \(em
- 3.1 kHz
- .LP
- \(em
- 64 kbit/s unrestricted
- .LP
- b)
- ISDN packet mode, X.31 case b)\(hyPSTN.
- .sp 1P
- .LP
- 6.3.2.2
- \fIISDN\(hyCSPDN\fR
- .sp 9p
- .RT
- .PP
- Applicable Recommendation: I.540.
- .RT
- .LP
- a)
- ISDN circuit mode\(hyCSPDN;
- .LP
- b)
- ISDN packet mode, X.31 case b)\(hyCSPDN
- .bp
- .sp 1P
- .LP
- 6.3.2.3
- \fIISDN\(hyPSPDN\fR
- .sp 9p
- .RT
- .PP
- Applicable Recommendation: I.550.
- .RT
- .LP
- a)
- ISDN circuit mode\(hyPSPDN;
- .LP
- b)
- ISDN circuit mode, to provide interworking port access
- to a PSPDN, X.31, case\ a);
- .LP
- c)
- ISDN packet mode, X.31 case b)\(hyPSPDN.
- .sp 1P
- .LP
- 6.3.2.4
- \fIISDN\(hyTelex\fR
- .sp 9p
- .RT
- .PP
- Applicable Recommendation: I.560.
- .RT
- .LP
- a)
- ISDN circuit mode\(hyTelex
- .LP
- b)
- ISDN packet mode\(hyTelex
- .sp 1P
- .LP
- 6.3.2.5
- \fIISDN\(hyPrivate networks\fR
- .sp 9p
- .RT
- .PP
- Interworking between ISDNs and private networks may occur at
- reference points S/T; other reference points, if required, need to be
- specified.
- .RT
- .sp 1P
- .LP
- 6.4
- \fIISDN internal interworking\fR
- .sp 9p
- .RT
- .PP
- Internal ISDN interworking involves the capabilities required for interworking
- between different connection elements within an ISDN, as well as the capabilities
- required to support other interworking requirements within an ISDN.
- .PP
- A reference configuration is given in Figure\ 7/I.510. The services
- offered at the endpoints may be different.
- .PP
- Not all aspects of internal ISDN interworking may be subject to
- standardization. The existence and functionality of such interworking,
- however, may have an impact on the required functionality of network interworking
- or
- ISDN\(hyto\(hyISDN interworking.
- .RT
- .LP
- .rs
- .sp 15P
- .ad r
- \fBFigure 7/I.510, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- 6.5
- \fINetwork concatenation configurations\fR
- .sp 9p
- .RT
- .PP
- \fINote\ 1\fR \ \(em\ The impact of network concatenation configurations
- (i.e.\ cascaded networks) on ISDN and existing networks and on the mechanisms
- and functionalities for the realization of these networks is for further
- study.
- .PP
- \fINote\ 2\fR \ \(em\ In the case of cascaded (concatenated) networks,
- other than ISDN networks, a requirement may exist for interworking functions
- between pairs of such networks.
- .bp
- .RT
- .sp 1P
- .LP
- 6.5.1
- \fIReference configurations\fR
- .sp 9p
- .RT
- .PP
- See Figure 8/I.510.
- .RT
- .LP
- .rs
- .sp 18P
- .ad r
- \fBFigure 8/I.510, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 2P
- .LP
- 6.5.2
- \fIConnection types\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 6.5.2.1
- \fIISDN\(hyPSTN\(hyISDN\fR
- .sp 9p
- .RT
- .PP
- Applicable alternatives at reference points K\dx\uare described in \(sc\
- 6.3.2.1 and in Recommendation\ I.520.
- .RT
- .sp 1P
- .LP
- 6.5.2.2
- \fIISDN\(hyPSPDN\(hyISDN\fR
- .sp 9p
- .RT
- .PP
- Applicable alternatives at reference points K\dx\uare described in \(sc\
- 6.3.2.3 and in Recommendation\ I.520.
- .RT
- .sp 1P
- .LP
- 6.5.2.3
- \fIISDN\(hyCSPDN\(hyISDN\fR
- .sp 9p
- .RT
- .PP
- Applicable alternatives at reference points K\dx\uare described in \(sc\
- 6.3.2.2 and in Recommendation\ I.520.
- .RT
- .sp 1P
- .LP
- 6.5.2.4
- \fIISDN\(hyPSPDN\(hyPSTN\fR
- .sp 9p
- .RT
- .PP
- Applicable alternatives at reference points K\dx\uare described in \(sc\
- 6.3.2.3.
- .RT
- .sp 1P
- .LP
- 6.5.2.5
- \fIISDN\(hyPSPDN\(hyCSPDN\fR
- .sp 9p
- .RT
- .PP
- Applicable alternatives at reference points K\dx\uare described in \(sc\
- 6.3.2.3.
- .RT
- .sp 1P
- .LP
- 6.5.2.6
- \fIISDN\(hyPSPDN\(hyTelex\fR
- .sp 9p
- .RT
- .PP
- Applicable alternatives at reference points K\dx\uare described in \(sc\
- 6.3.2.3.
- .RT
- .sp 1P
- .LP
- 6.5.2.7
- \fIISDN\(hyCSPDN\(hyPSPDN\fR
- .sp 9p
- .RT
- .PP
- Applicable alternatives at reference points K\dx\uare described in \(sc\
- 6.3.2.2.
- .bp
- .RT
- .sp 2P
- .LP
- \fB7\fR \fBInterworking functional requirements \(em General aspects\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 7.1
- \fICategories of interworking functions\fR
- .sp 9p
- .RT
- .PP
- The following network\(hyrelated characteristics and protocols depend on
- the network type (ISDN circuit\(hyswitched, ISDN packet\(hyswitched, PSTN,
- CSPDN, PSPDN,\ etc.) and may be identified at the point of network interworking
- for
- conversion or mapping:
- .RT
- .LP
- a)
- network characteristics related to the connection type,
- such as interface characteristics, switching mode, bit rate,
- transfer mode,\ etc., and non\(hyprotocol conversion\(hyrelated
- characteristics such as numbering plan and special
- routing;
- .LP
- b)
- network\(hyto\(hynetwork protocols used for call establishment
- interexchange signalling, such as SS No.\ 7, X.71, X.75,\ etc.
- (e.g.\ SS No.\ 7 ISUP to another User Part of SS No.\ 7, SS No.7 to
- non\(hyISDN signalling system, D\(hychannel signalling to non\(hyISDN
- user access signalling systems based on national
- standards);
- .LP
- c)
- protocols used for the support of those supplementary
- services and service signals which have network\(hyto\(hynetwork
- relevance, as in the case, for example, of the closed user
- group facility;
- .LP
- d)
- signals due to network operation and
- maintenance;
- .LP
- e)
- inband protocol conversion IWFs such as rate adaption,
- modem pools, and generation of inband tones and
- announcements.
- .PP
- The definition of the conversion or mapping functions is
- the subject of specific interworking Recommendations which address ISDN
- interworking at a functional level of detail (see
- Recommendation\ I.500).
- .PP
- Interworking functional must take into account the mapping of
- protocols (protocol elements) dedicated to the support of OSI network layer
- service characteristics. These requirements should be formulated with the
- recognition that the networks involved in ISDN interworking may support the
- OSI network layer service as defined in Recommendation\ X.213 in different
- ways and to different extents (see Recommendation\ X.300,\ \(sc\ 6).
- .RT
- .sp 1P
- .LP
- 7.2
- \fIMapping principles\fR
- .sp 9p
- .RT
- .PP
- Interworking implies the transfer of information between two
- different entities across an interface. This transfer may imply the need to
- map different protocols with respect to coding, sequencing, and timing.
- Ideally, no information content should be lost in mapping. This objective
- may not be achievable in all circumstances. Three different cases are
- identified:
- .RT
- .LP
- a)
- one\(hyto\(hyone mapping, where the information is transferred
- across the interface without any loss;
- .LP
- b)
- mapping with degraded information transfer, where parts of
- information are lost when crossing the interface;
- .LP
- c)
- no meaningful mapping possible, due to the fact that
- crucial parts of one protocol cannot be represented in the
- other protocol.
- .PP
- In these cases, appropriate actions have to be taken at the
- interworking point with respect to one or both of the communicating
- entities.
- .sp 1P
- .LP
- 7.3
- \fIGuidelines on the description of mapping functions\fR
- .sp 9p
- .RT
- .PP
- For further study.
- .RT
- .sp 1P
- .LP
- 7.4
- \fIFunctional requirements for lower layer service interworking\fR
- .sp 9p
- .RT
- .PP
- (For example, mapping of layer\ 2 and layer\ 3 protocols by end
- systems in support of end\(hyto\(hyend communication).
- .PP
- For further study.
- .RT
- .sp 1P
- .LP
- 7.5
- \fIFunctional requirements for higher layer service interworking\fR
- .sp 9p
- .RT
- .PP
- For further study.
- .bp
- .RT
- .sp 2P
- .LP
- \fB8\fR \fBGeneral aspects of \fR \fBselection mechanisms for interworking\fR
- \fBfunctions\fR
- .sp 1P
- .RT
- .PP
- ISDN interworking will involve sets of different functional
- elements dedicated to the various cases of network interworking. For each
- call where interworking is required, specific interworking functions have
- to be
- selected (see Figure\ 9/I.510).
- .RT
- .LP
- .rs
- .sp 22P
- .ad r
- \fBFigure 9/I.510, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- When the IWF is not an addressed entity, the following concept for the
- selection of interworking functions is therefore defined:
- .LP
- a)
- Connection\(hydependent interworking functions are selected
- by evaluation of user\(hynetwork and network\(hynetwork
- signalling information. Relevant information includes:
- .LP
- \(em
- bearer capability,
- .LP
- \(em
- low layer compatibility,
- .LP
- \(em
- service indication,
- .LP
- \(em
- routing information (address information, transit
- network information),
- .LP
- \(em
- information on supplementary services (facilities),
- if applicable;
- .LP
- b)
- Network\(hyprovided communication\(hydependent interworking
- functions are selected by evaluation of user\(hynetwork and
- network\(hynetwork signalling information. Relevant information
- includes:
- .LP
- \(em
- service indication,
- .LP
- \(em
- lower and higher layer compatibility
- information,
- .LP
- \(em
- information on supplementary services (facilities),
- if applicable;
- .LP
- c)
- End\(hysystem\(hyprovided communication\(hydependent interworking
- functions, if available, are activated by one of the
- following approaches:
- .LP
- \(em
- by evaluation of user\(hynetwork signalling information
- during the call establishment phase (service
- indication and lower/higher compatibility
- information),
- .LP
- \(em
- by evaluation of user\(hyto\(hyuser compatibility
- information during the parameter exchange
- phase.
- .PP
- \fINote\fR \ \(em\ Examination of these information elements requires
- further study.
- .bp
- .sp 2P
- .LP
- \fBRecommendation\ I.511\fR
- .RT
- .sp 2P
- .sp 1P
- .ce 1000
- \fBISDN\(hyTO\(hyISDN\ LAYER\ 1\ INTERNETWORK\ INTERFACE\fR
- .EF '% Fascicle\ III.9\ \(em\ Rec.\ I.511''
- .OF '''Fascicle\ III.9\ \(em\ Rec.\ I.511 %'
- .ce 0
- .sp 1P
- .ce 1000
- \fI(Melbourne, 1988)\fR
- .sp 9p
- .RT
- .ce 0
- .sp 1P
- .LP
- \fB1\fR \fBGeneral\fR
- .sp 1P
- .RT
- .PP
- The objective of this Recommendation is to define the layer 1
- aspects of the ISDN interworking, including reference configuration and
- interworking functions.
- .PP
- \fINote\fR \ \(em\ For the international interworking between networks
- based on different digital hierarchies and speech encoding laws, see
- Recommendation\ G.802.
- .RT
- .sp 2P
- .LP
- \fB2\fR \fBReference configuration\fR
- .sp 1P
- .RT
- .PP
- General reference configuration and logically defined reference
- points for ISDN interworking with other networks or other\ ISDNs are given in
- Figure\ 4/I.310, where\ K, M and\ N are defined as logical reference points
- for interworking. However, from the viewpoint of physical interworking, the
- digital sections and digital links defined in Rec.\ G.701 are shared among
- the logically different networks of the same network provider. Therefore,
- the
- commonly designated reference point for layer\ 1 interworking should be
- established so that it can be used as the common layer\ 1 specification
- for the logically different reference points\ K, M and\ N.
- .RT
- .sp 1P
- .LP
- 2.1
- \fILayer 1 reference configuration\fR
- .sp 9p
- .RT
- .PP
- Figure 1/I.511 shows the layer 1 reference configuration and
- layer\ 1 reference point\ Q.
- .PP
- Figure 1/I.511 reflects the interworking between different network
- providers each of which has logically different networks or special facilities.
- The number of logically different networks which a network provider has
- is one or more; however, at least one network provider should contain
- an\ ISDN.
- .PP
- The internetwork termination\ (IT) is a functional grouping
- associated with the proper physical and electromagnetic termination of the
- network as well as section, link and/or circuit termination of the network.
- Note that specific functions of IT may be performed with one or more pieces
- of equipment.
- .PP
- Reference point Q should be one of the equipment interfaces listed
- in Recs.\ G.702 and\ G.707. The specification of\ Q can be used as the common
- description of the layer\ 1 specification for the different logical
- interfaces\ K, M and\ N.
- .PP
- The digital link of each network should be terminated at\ Q.
- .RT
- .sp 1P
- .LP
- 2.2
- \fIPhysical realizations of reference configuration\fR
- .sp 9p
- .RT
- .PP
- Figure 2/I.511 gives examples of configurations made up of
- combinations of physical interfaces at reference point\ Q; Figure\ 2a/I.511
- shows an interface without transmission section (line or radio); and
- Figures\ 2b/I.511 and\ 2c/I.511 show interfaces with transmission
- sections.
- .PP
- In every case,
- reference point\ Q
- should appear as the
- equipment interface.
- .PP
- The mandatory functions of IT described in \(sc\ 3 are the same in each
- application, while the optional functions may be different according to the
- following cases, if interworking:
- .RT
- .LP
- \(em
- with or without transmission sections,
- .LP
- \(em
- with or without master\(hyslave relation, such as master\(hyslave
- synchronization and remote maintenance between two network
- providers.
- .sp 2P
- .LP
- \fB3\fR \fBLayer 1 interworking functions\fR
- .sp 1P
- .RT
- .PP
- Layer\ 1 interworking functions at Q, which may be performed
- by the IT, should be classified into mandatory and optional
- functions.
- .bp
- .RT
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1/I.511, (N), p. 11\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 2/I.511, (N), p. 12\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- 3.1
- \fIMandatory functions\fR
- .sp 9p
- .RT
- .PP
- Every item related to mandatory functions should always
- be carried out in order be classified into mandatory and optional
- functions.
- .RT
- .sp 1P
- .LP
- 3.1.1
- \fIProviding standardized equipment interfaces\fR
- .sp 9p
- .RT
- .PP
- Reference point Q should be applied to one of the equipment
- interfaces standardized in the G.700\(hyG.900\ Series Recommendations for
- digital networks, transmission systems and multiplexing equipment.
- .PP
- Items to be standardized are as follows:
- .RT
- .LP
- 1)
- \fIInterface bit rate\fR
- .LP
- Interface bit rate at Q should be selected from among the
- hierarchical bit rates defined in Recs.\ G.702
- and\ G.707.
- .LP
- It should be noted that the interworking hierarchy be
- applied to the international interworking as defined in
- Rec.\ G.802 when interconnection based on an asynchronous
- hierarchy is adopted.
- .LP
- 2)
- \fIPhysical/electrical characteristics\fR
- .LP
- Physical/electrical characteristics at Q should conform to
- the relevant part of G.700\(hyG.900\ Series
- Recommendations.
- .LP
- 3)
- \fIFunctional characteristics\fR
- .LP
- Functional characteristics at Q should conform to the
- relevant part of G.700\(hyG.900\ Series
- Recommendations.
- .LP
- 4)
- \fITime slot assignment\fR
- .LP
- There are two methods for assigning time slots in the frame
- structure to various channels: the fixed format method and
- the variable format method. A set of examples of both
- methods is described in Figure\ 3/I.511.
- .LP
- \fIFixed format\fR \ \(em\ Time slots for interworking information
- channels are pre\(hyassigned in a fixed manner in the
- interworking frame structure by bilateral
- negotiation.
- .LP
- \fIVariable format\fR \ \(em\ A flexible time slot is allocated to any
- information channel on a demand assignment basis.
- .LP
- 5)
- \fITime slot sequence integrity\fR
- .LP
- Time slot sequence integrity should be performed.
- Furthermore, it is preferable to perform time slot sequence
- integrity with 8\ kHz integrity.
- .LP
- \fI\fR .rs
- .sp 20P
- .ad r
- \fBFigure 3/I.511, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- 3.1.2
- \fIProviding layer 1 maintenance capability\fR
- .sp 9p
- .RT
- .PP
- Reference point Q should meet the maintenance requirements defined in the
- relevant part of the M\(hySeries and N\(hySeries Recommendations.
- .PP
- Items to be standardized are as follows:
- .RT
- .LP
- 1)
- \fITermination of the digital link\fR
- .LP
- Termination of the digital link should conform
- to the relevant part of the M\(hySeries
- Recommendations.
- .LP
- 2)
- \fITermination of the digital circuit\fR
- .LP
- Termination of the digital circuit should conform
- to the relevant part of the M\(hySeries Recommendations and is
- deferred for further study.
- .sp 1P
- .LP
- 3.2
- \fIOptional functions\fR
- .sp 9p
- .RT
- .PP
- Not all of the items of the optional functions can be achieved at reference
- point\ Q. Only some of them are selected according to the features of each
- connection type or differences in the relationship between network
- providers.
- .RT
- .sp 1P
- .LP
- 3.2.1
- \fIProviding interworking between different connection types\fR
- \fIin layer\ 1\fR
- .sp 9p
- .RT
- .PP
- In some applications, connection types which are different in
- layer\ 1 items can be successfully interconnected over reference point\ Q by
- using the optional capabilities listed below.
- .PP
- Items to be standardized are as follows:
- .RT
- .LP
- 1)
- \fICoding rule conversion\fR
- .LP
- i)
- \(*m\(hyA law coding rule conversion should be performed
- according to Rec.\ G.802 in the case of speech and
- 3.1\ kHz audio services;
- .LP
- ii)
- Unrestricted 64\ kbit/s digital service shall not be
- subject to network provided conversion.
- .LP
- 2)
- \fIInterconnection among connection types with different\fR \fIlayer\
- 1 attributes\fR
- .LP
- Rate adaption should be performed according to
- Recs.\ I.460, I.461, I.462, I.463
- and\ I.464.
- .sp 1P
- .LP
- 3.2.2
- \fIProviding network synchronization clock\fR
- .sp 9p
- .RT
- .PP
- If network synchronization is performed over reference point Q by other
- methods than the plesiochronous method, the clock should meet the
- requirement defined in Rec.\ G.812.
- .RT
- .sp 2P
- .LP
- \fBRecommendation\ I.515\fR
- .RT
- .sp 2P
- .sp 1P
- .ce 1000
- \fBPARAMETER\ EXCHANGE\ FOR\ ISDN\ INTERWORKING\fR
- .EF '% Fascicle\ III.9\ \(em\ Rec.\ I.515''
- .OF '''Fascicle\ III.9\ \(em\ Rec.\ I.515 %'
- .ce 0
- .sp 1P
- .ce 1000
- \fI(Melbourne, 1988)\fR
- .sp 9p
- .RT
- .ce 0
- .sp 1P
- .LP
- \fB1\fR \fBGeneral\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 1.1
- \fIScope\fR
- .sp 9p
- .RT
- .PP
- The objective of this Recommendation is to provide overall
- parameter exchange principles and functional descriptions for ISDN
- interworking. This Recommendation describes the principles for parameter
- exchange mechanisms. It is recognized that depending on the available
- (end\(hyto\(hyend) signalling capability, the exchange of parameters may
- use either out\(hy or in\(hyband procedures.
- .PP
- Parameter exchange may be necessary to establish compatible
- interworking functions for a variety of applications. Typical examples where
- parameter exchange takes place include, terminal adaption compatibility
- establishment, modem type selection and voice encoding compatibility
- establishment. This does not imply, however, any requirement for an ISDN to
- support network based modem interworking.
- .bp
- .PP
- Figure 1/I.515 illustrates several voice and data applications,
- supported by different networks and mechanisms. Parameter exchange may be
- necessary where interworking between different terminals or networks (as per
- other Recommendations) is required.
- .PP
- \fINote\fR \ \(em\ Where interworking procedures exist, the appropriate
- references are made herein.
- .RT
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure 1/I.515, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- 1.2
- \fIDefinitions and abbreviations\fR
- .sp 9p
- .RT
- .PP
- Use is made of the following terms within this Recommendation.
- These terms do not necessarily refer to any existing protocol structure,
- rather they define information requirements in the context of this
- Recommendation.
- .RT
- .LP
- \(em
- \fBbearer capability information\fR
- .LP
- Specific information defining the lower layer
- characteristics of the network.
- .LP
- \(em
- \fBlow layer compatibility information\fR
- .LP
- Information defining the lower layer characteristics of a
- TE or TA.
- .LP
- \(em
- \fBhigh layer compatibility information\fR
- .LP
- Information defining the higher layer characteristics of a
- terminal.
- .LP
- \(em
- \fBprotocol identifier\fR
- .LP
- Information defining the specific protocols used by a
- terminal to support data transfer.
- .LP
- \(em
- \fBprogress indicator\fR
- .LP
- Information supplied to indicate to the ISDN terminal that
- interworking has occurred.
- .LP
- \(em
- \fBout\(hyband parameter exchange\fR
- .LP
- Information exchanged via signalling channels which are not
- within the channel used for user information
- transfer.
- .LP
- \(em
- \fBin\(hyband parameter exchange\fR
- .LP
- Information exchanged using the same information channel as
- that used for the user information transfer.
- .sp 2P
- .LP
- \fB2\fR \fBPrinciples\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 2.1
- \fITypes of parameter exchanges\fR
- .sp 9p
- .RT
- .PP
- Three types of parameter exchange need to be
- considered:
- .RT
- .LP
- i)
- end\(hyto\(hyend, out\(hyband as shown in Figure\ 2/I.515. Parameter
- exchange is accomplished via the D\(hychannel and Signalling
- Systems\ No.\ 7;
- .LP
- ii)
- end\(hyto\(hyend, in\(hyband as shown in Figure\ 3/I.515.
- .LP
- iii)
- Parameter exchange to select IWFs as shown in
- Figure\ 4/I.515.
- .PP
- The in\(hyband parameter exchange occurs after the establishment of an
- end\(hyto\(hyend connection and may provide for establishment of compatibility
- between the endpoints, based on characteristics such as protocol, rate
- adaption scheme and modem type.
- .sp 1P
- .LP
- 2.2
- \fIRelationship of\fR
- \fIparameter exchange\fR \fIto\fR
- \fIcall\fR
- \fIestablishment\fR
- .sp 9p
- .RT
- .PP
- Parameter exchange may occur:
- .RT
- .LP
- i)
- prior to call establishment (call negotiation). In this
- case parameter exchange will occur using out\(hyband
- techniques;
- .LP
- ii)
- after call establishment, prior to information transfer.
- In this case parameter exchange may occur using either
- in\(hyband or out\(hyband techniques;
- .LP
- iii)
- during the information transfer phase of the call. In this
- case parameter exchange will occur using either in\(hyband or
- out\(hyband techniques.
- .sp 1P
- .LP
- 2.2.1
- \fIParameter exchange prior to call establishment (call\fR
- \fInegotiation)\fR
- .sp 9p
- .RT
- .PP
- Call negotiation
- may be used to satisfy a number of basic call requirements in ISDN. In
- addition, call negotiation may be necessary for interworking as described
- in\ I.510 (between terminals, services and networks) for:
- .RT
- .LP
- a)
- terminal section (see Recs.\ I.333, Q.931, Q.932);
- .LP
- b)
- selection of interworking requirements when interworking
- between ISDN and other dedicated networks is identified
- (e.g. modem type);
- .LP
- c)
- the appropriate selection of network (ISDN or other
- network) functions to support the service required
- (e.g. use of call progress indicator);
- .LP
- d)
- the selection of network functions when interworking between
- incompatible terminals is identified or when interworking of
- different services is required.
- .PP
- Each of the requirements a) through d) above are necessary during the call
- establishment phase. Therefore, call or service negotiation mechanisms
- should be included within basic call establishment procedures. Further
- study is required.
- .bp
- .LP
- .rs
- .sp 9P
- .ad r
- \fBFigure 2/I.515, (N), p. 15\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .rs
- .sp 21P
- .ad r
- \fBFigure 3/I.515, (N), p. 16\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .rs
- .sp 9P
- .ad r
- \fBFigure 4/I.515, (N), p. 17\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- 2.2.1.1
- \fICall negotiation types\fR
- .sp 9p
- .RT
- .PP
- Three types of call negotiation are currently
- envisaged:
- .RT
- .LP
- \(em
- user to network,
- .LP
- \(em
- network to user,
- .LP
- \(em
- user to user.
- .PP
- The relationship between user\(hyto\(hyuser call negotiation and
- network\(hyto\(hyuser call negotiation required further study.
- .PP
- Call negotiation in each of the above cases may involve the forwarding
- of parameters to the destination, may involve forwarding of parameters
- on
- request, or may involve forward and backward negotiation to establish
- compatible terminal and network parameters.
- .RT
- .sp 1P
- .LP
- 2.2.1.2
- \fIInformation elements available for call negotiation\fR
- .sp 9p
- .RT
- .PP
- Three information elements are currently associated with call
- negotiation (see note):
- .RT
- .LP
- \(em
- bearer capability (BC);
- .LP
- \(em
- low layer compatibility (LLC);
- .LP
- \(em
- high layer compatibility (HLC).
- .PP
- The relationship of these information elements to parameter
- exchange functions is for further study.
- .PP
- \fINote\fR \ \(em\ BC, LLC, HLC are information elements defined in
- Recommendation\ Q.931.
- .RT
- .sp 1P
- .LP
- 2.2.1.3
- \fITransfer of information\fR
- .sp 9p
- .RT
- .PP
- The transfer of information associated with call negotiation is
- illustrated in figure\ 5/I.515.
- .RT
- .LP
- .rs
- .sp 30P
- .ad r
- \fBFigure 5/I.515, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- 2.2.2
- \fIParameter exchange after call establishment and prior to\fR
- \fIinformation transfer phase\fR
- .sp 9p
- .RT
- .PP
- This parameter exchange may be necessary when signalling to allow adequate
- compatibility checking during the call set\(hyup phase is not available,
- or when additional capability checking is required due to characteristics
- of
- the terminals which are not defined in call establishment procedures.
- .PP
- When out\(hyband parameter exchange is used refer to
- \(sc\ 3.1.2.
- .PP
- When in\(hyband paramaeter exchange is used refer to
- \(sc\ 3.2.1.
- .RT
- .sp 1P
- .LP
- 2.2.3
- \fIParameter exchange during information transfer phase\fR
- .sp 9p
- .RT
- .PP
- This parameter exchange may be necessary when configurations change during
- the information transfer phase (e.g. maintenance, sub\(hychannel
- information). Detailed aspects are for further study.
- .RT
- .LP
- \fB3\fR \fBParameter exchange procedures\fR
- .sp 1P
- .RT
- .sp 2P
- .LP
- 3.1
- \fIOut\(hyband parameter exchange\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 3.1.1
- \fIPrior to call establishment\fR
- .sp 9p
- .RT
- .PP
- Refer to Recs.\ Q.931 and Q.\ 764. Other protocols are for further
- study.
- .RT
- .sp 1P
- .LP
- 3.1.2
- \fIAfter call establishment and prior to information transfer phase\fR
- .sp 9p
- .RT
- .PP
- Refer to Recs.\ Q.931 and\ Q.764.
- .RT
- .sp 1P
- .LP
- 3.1.3
- \fIDuring information transfer phase\fR
- .sp 9p
- .RT
- .PP
- Refer to Recs.\ Q.931 and\ Q.764.
- .RT
- .sp 2P
- .LP
- 3.2
- \fIIn\(hyband parameter exchange\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 3.2.1
- \fIAfter call establishment and prior to information transfer\fR
- .sp 9p
- .RT
- .PP
- The following parameter exchange sequence identifies one method of establishment
- compatibility during interworking between an ISDN and existing
- networks and between ISDNs:
- .RT
- .LP
- \(em
- call establishment phase (e.g. refer to Recs.\ Q.931
- and\ Q.764);
- .LP
- \(em
- originating terminal changes from idle condition to busy
- condition;
- .LP
- \(em
- connection enters paramters exchange phase;
- .LP
- \(em
- connection enters information transfer
- phase.
- .sp 1P
- .LP
- 3.2.1.1
- \fIVoice services\fR
- .sp 9p
- .RT
- .PP
- Refers to Recommendation G.725.
- .RT
- .sp 1P
- .LP
- 3.2.1.2
- \fIParameter exchange mechanism for terminal adaption protocol\fR
- \fIidentification\fR
- .sp 9p
- .RT
- .PP
- Some In\(hyband Parameter Exchange (IPE) procedures are in
- existence, e.g.\ Appendix\ I of Recommendation\ V.110. Two circuit mode
- terminal adaption procedures are emerging within CCITT (i.e.\ I.463/V.110
- and
- I.465/V.120). In many countries, the Terminal Adaptor\ (TA) desing may not be
- controlled by the administration/RPOAs so that special forms of terminal
- adaption may be deployed. To support multiple forms of terminal adaption
- in a mixed ISDN/non\(hyISDN network, terminal adaption implementations
- which support
- multiple terminal adaption protocols will be required. For use with such
- implementations, a method is needed for some applications to identify the
- specific terminal adaption protocol to be used by the multifunctional
- adaptor\ (MTA) devices. This will allow the terminal equipment (or appropriate
- network component), to release the call where compatibility cannot be achieved,
- or to request the network to provide an appropriate interworking function.
- .bp
- .PP
- It should be noted that it is good practice to design data terminals, for
- circuit\(hymode applications, which can automatically answer or originate
- calls, automatically establish compatibility if possible and, if necessary,
- to disconnect when connected to an incompatible terminal.
- .PP
- Though it is recognized that out\(hyband procedures are preferable where
- applicable (i.e., intra\(hyISDN situations), for interworking with dedicated
- networks, in\(hyband parameter exchange procedures may be required.
- .PP
- Alternative methods exist for distinguishing between terminal
- adapttion protocols. One satisfactory method is the use of self identification
- by examining the incoming bit stream. The method would be sed on the need
- to
- provide, in any TA or TE1, the ability to determine when it is connected
- to an incompatible TE1 or TA/TE2 or, through an IWF, with an incompatible
- terminal or another network. Appendix\ II describes one such procedure.
- .PP
- An alternative satisfactory method is to use protocol identification (PID)
- procedure. Appendix\ I presents an in\(hyband parameter exchange procedure
- for establishing a common terminal adaption\ (TA) protocol between
- communicating\ TA devices.
- .RT
- .sp 1P
- .LP
- 3.2.2
- \fIDuring the information transfer phase\fR
- .sp 9p
- .RT
- .PP
- For further study.
- .RT
- .sp 2P
- .LP
- \fB4\fR \fBParameter exchange functions\fR
- .sp 1P
- .RT
- .PP
- Parameters exchanged to support interworking may be divided into
- the following three categories. These parameters may be exchanged end\(hyto\(hyend
- or between an endpoint and an IWF. The list of parameters presented here
- are
- examples; for any given instances of communication, different parameters
- may be required.
- .RT
- .sp 1P
- .LP
- 4.1
- \fINumbering parameters\fR
- .sp 9p
- .RT
- .LP
- \(em
- subscriber number;
- .LP
- \(em
- sub\(hyaddress;
- .LP
- \(em
- terminal selection
- (see Recommendation\ I.333).
- .sp 1P
- .LP
- 4.2
- \fIProtocol control parameters\fR
- .sp 9p
- .RT
- .PP
- Protocol control parameters can be used to identify the protocol
- supported. An example is the terminal adaption protocol supported, such
- as V.110, V.120.
- .RT
- .sp 1P
- .LP
- 4.3
- \fIDTE/DCE configuration parameters\fR
- .sp 9p
- .RT
- .PP
- DTE/DCE configuration parameters are used to identify specific
- transmission or communication capabilities of the called DTE. The following
- is a list of such configuration parameters:
- .RT
- .LP
- \(em
- modem type (e.g., V\(hySeries number)
- .LP
- \(em
- data rate (e.g., 9.6 kbit/s, 56 kbit/s)
- .LP
- \(em
- synchronization (e.g., synchronous or
- asynchronous)
- .LP
- \(em
- parity (odd, even or no parity)
- .LP
- \(em
- transmission mode (e.g., half or full duplex)
- .LP
- \(em
- number of start/stop bits (e.g., 1\ or\ 2)
- .LP
- \(em
- terminal clock source (e.g., network provided, network
- independent)
- .LP
- \(em
- terminal interface signals (e.g., 106, 108)
- .LP
- \(em
- sub\(hychannel information.
- .sp 1P
- .LP
- 4.4
- \fIOperations and maintenance parameters\fR
- .sp 9p
- .RT
- .PP
- Operations and maintenance parameters are used to convey/monitor
- the status of the DTE/DCE at the terminating points. Status monitored may
- include:
- .RT
- .LP
- \(em
- terminal power (ON or OFF)
- .LP
- \(em
- terminal presence (connected or disconnected)
- .LP
- \(em
- terminal interface signals status (e.g., 106, 108)
- .LP
- \(em
- terminal clock source (e.g., network provided, network
- independent)
- .LP
- \(em
- loopback status (e.g., ON or OFF)
- .bp
- .sp 2P
- .LP
- \fB5\fR \fBParameter exchange for selection of IWF\fR
- .sp 1P
- .RT
- .PP
- When an IWF is involved in a connection, parameters can be
- exchanged to establish compatibility.
- .PP
- There are a variety of techniques that can be used to provide
- compatibility of functions in an interworking environment. These can be
- categorized into two types. A single stage approach in which the network
- automatically inserts the IWF, and a two\(hystage approach in which the user
- must provide additional information to complete the interworking
- connection.
- .PP
- \fINote\fR \ \(em\ For examples of interworking configurations, refer to the
- appropriate I.500\(hySeries Recommendations. Appendix\ III details examples of
- parameter exchange for the selection of IWFs in the case of ISDN\(hyPSTN
- interworking for data.
- .RT
- .sp 1P
- .LP
- 5.1
- \fISingle stage\fR
- .sp 9p
- .RT
- .PP
- In a single stage approach, the interworking function is handled
- automatically by the network. In order to ensure compatibility of the
- parameters the following techniques may be used:
- .RT
- .LP
- i)
- parameter registration (
- service profile
- )\ \(em\ the
- DTE/DCE parameters are registered with
- the ISDN;
- .LP
- ii)
- parameter negotiation\ \(em\ parameter negotiation may be
- possible between networks and end\(hyusers or between
- networks or between users to determine parameter
- compatibility where suitable signalling exists. The
- signalling capabilities and parameters required
- may vary and are for further study. For example, see
- Appendix\ I of\ V.110;
- .LP
- iii)
- default parameter
- identification\ \(em\ the network
- provides an interworking function with common parameters.
- Any DCE must conform to the IWF common parameters;
- .LP
- iv)
- parameter adaption
- \ \(em\ the interworking function
- recognizes and adapts to the end\(hyuser's parameters. For
- example, for ISDN\(hyPSTN the interworking function may adapt
- to the modulation standard of the modem (see
- Appendix\ III).
- .sp 1P
- .LP
- 5.2
- \fITwo stages\fR
- .sp 9p
- .RT
- .PP
- In the two\(hystage approach, during the first stage the user accesses
- the IWF and establishes the required parameters. In the second stage of
- the
- call the IWF uses the parameters to complete the end\(hyto\(hyend
- connection.
- .RT
- .sp 2P
- .LP
- \fB6\fR \fBReference\fR
- .sp 1P
- .RT
- .PP
- See Recommendation\ I.500.
- .RT
- .ce 1000
- APPENDIX\ I
- .ce 0
- .ce 1000
- (to Recommendation I.515)
- .sp 9p
- .RT
- .ce 0
- .ce 1000
- \fBProtocol for identification of terminal adaption protocols\fR
- .sp 1P
- .RT
- .ce 0
- .PP
- I.1
- As shown in Figure I\(hy1/I.515 the total in\(hyband parameter exchange
- consists of two distinct phases. These are:
- .sp 1P
- .RT
- .LP
- a)
- Phase\ 1\ \(em
- the protocol identification (PID) phase,
- which occurs at the bearer rate (64\ kbit/s);
- .LP
- b)
- Phase\ 2\ \(em
- the in\(hyband parameter exchange (IPE) which
- is part of the rate adaption (RA) protocol used
- during the call.
- .PP
- Both these phases are optional and may or may not be implemented depending
- on the particular situation.
- .LP
- 1)
- Phase\ 1\ \(em
- PID: after call establishment PID phase
- begins.
- .LP
- 2)
- Phase\ 2\ \(em
- IPE: the IPE is imbedded within the TA
- protocol. It is the responsibility of the RA
- protocol designers to create an IPE that is
- applicable to the services and requirements of a
- particular TA protocol. An example is Appendix\ I to
- Rec.\ V.110 in which a complete IPE is specified
- for\ V.110.
- .LP
- \(em
- The IPE allows parameters to be exchanged between TA
- devices to ensure end\(hyto\(hyend compatibility before
- entering the data (information) phase.
- .LP
- \(em
- In the case of a successful IPE the protocol enters the
- data (information) phase.
- .LP
- \(em
- In the case of unresolvable differences between the TA
- devices, the IPE will provide a call progress message
- that can be used to take further action or clear the
- call.
- .bp
- .LP
- .rs
- .sp 40P
- .ad r
- \fBFigure I\(hy1/I.515, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- I.2
- \fIIdentification procedure\fR
- .sp 9p
- .RT
- .PP
- All TA devices that follow this procedure shall start with the
- simple protocol identification technique described here before entering
- the TA protocol phase. The method is designed especially for digital
- networks.
- .PP
- The
- protocol identification
- is performed during the following three steps after the call is placed
- by using the normal call establishment
- procedures:
- .RT
- .LP
- 1)
- end\(hyto\(hyend synchronization;
- .LP
- 2)
- passing the Protocol Identifier (PI);
- .LP
- 3)
- making a decision regarding the type of TA to use for the
- call.
- .bp
- .PP
- For the case of a device with a PID and one without a PID which
- interwork, a timer value (\fIN\fR\d\fIp\fR\\d\fIi\fR\\d\fId\fR\u) should
- be set in the PID for defaulting to the preferred terminal adaption protocol.
- \fIN\fR\d\fIp\fR\\d\fIi\fR\\d\fId\fR\umust be long enough to allow for
- initial line settling and short enough to prevent the PID from causing
- the terminal adaption protocol to time out and clear its call. The value
- of timer \fIN\fR\d\fIp\fR\\d\fIi\fR\\d\fId\fR\ushould be set to allow for
- long delay
- connections (e.g. satellites).
- .PP
- Refer to Figure\ I\(hy2/I.515 for the timer sequence diagram of a
- successful protocol identification procedure. The sequence and acronyms in
- Figure\ I\(hy2/I.515 are described in \(sc\(sc\ I.3 to\ I.5.
- .RT
- .LP
- .rs
- .sp 45P
- .ad r
- \fBFigure I\(hy2/I.515, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- I.3
- \fIEnd\(hyto\(hyend synchronization\fR
- .sp 9p
- .RT
- .PP
- After the physical call has been established, the originating end sends
- continuous ready bytes (5Fhex) waiting to detect the answering
- end. The answering end sends continuous sync bytes (57hex). (See
- Figure\ I\(hy3/I.515).
- .PP
- When the originating end sees at least 32 contiguous sync bytes
- (57hex) it is in sync and starts sending continuous sync bytes (57hex).
- .PP
- When the answering end sees 32 contiguous sync bytes it is in
- sync.
- .PP
- The receivers at each end wait for at least 32 contiguous
- occurrences (4\ ms) of the sync byte to be received without corruption before
- initiating the protocol. The sequence can then proceed to the next
- step.
- .PP
- The synchronization method described in this section allows
- for:
- .RT
- .LP
- 1)
- settling of the physical circuit;
- .LP
- 2)
- notice in the network;
- .LP
- 3)
- positive identification of the fact that TA devices are
- present at both ends;
- .LP
- 4)
- transmission on restricted 64 kbit/s links and through
- networks that use bit\ 8 for signalling; and
- .LP
- 5)
- simple implementation.
- .ce
- \fBH.T. [T1.515]\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- lw(36p) | cw(18p) sw(18p) sw(18p) sw(18p) sw(18p) sw(18p) sw(18p) sw(18p) sw(36p) , ^ | c | c | c | c | c | c | c | c | l.
- Initialization bytes
- B1 B2 B3 B4 B5 B6 B7 B8
- _
- .T&
- lw(36p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(36p) .
- Originating end 0 1 0 1 1 1 1 1 (5F in hexadecimal)
- _
- .T&
- lw(36p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(36p) .
- Answering end 0 1 0 1 0 1 1 1 {
- (57 in
- hexadecimal)
- }
- .TE
- .LP
- \fINote\ 1\fR
- \ \(em\ B1 is transmitted and received first.
- .LP
- \fINote\ 2\fR
- \ \(em\ B8 is set to 1 for transmission and ignored
- on reception.
- .LP
- FIGURE\ I\(hy3/I.515
- .nr PS 9
- .RT
- .ad r
- \fBFigure I\(hy3/I.515 (comme tableau) [T1.515], p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- I.4
- \fIPassing the protocol identifier\fR \fI(PI)\fR
- .sp 9p
- .RT
- .PP
- This is the critical information that is to be passed and therefore a special
- technique is used to provide robustness in the face of noise, and yet maintain
- simplicity.
- .PP
- The PI is split into two bytes and three identical pairs are sent
- (refer to Figure\ I\(hy4/I.515).
- .RT
- .PP
- The PI passing technique described in this section:
- .LP
- 1)
- provides positive identification of the protocol bytes
- (low and high byte codes);
- .LP
- 2)
- provides redundant pairs of byte codes which allows for a
- technique to determine the protocol identification in the
- presence of noise (i.e. repeated three times);
- .LP
- 3)
- allows all eight bits of the PI to be used even on networks
- that use bit\ 8 for signalling; and
- .LP
- 4)
- allows for operation on restricted 64\ kbit/s networks and
- networks that use bit\ 8 for signalling (i.e. guarantees
- one's density, bit\ 8 set to\ 1).
- .sp 1P
- .LP
- I.5
- \fITA decision\fR
- .sp 9p
- .RT
- .PP
- After the answering end has received 32 contiguous sync\(hybytes
- (\(sc\ I.3), it then sends its PI. The protocols supported by the answering
- end are coded in the PI byte (see Figure\ I\(hy5/I.515) and transmitted
- to the originating end. The originating end will check the PI and decide
- which (if any) TA
- protocol it wishes to support.
- .bp
- .RT
- .LP
- .rs
- .sp 19P
- .ad r
- \fBFigure I\(hy4/I.515, (N), p. 22\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .ce
- \fBH.T. [T2.515]\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- P7 P6 P5 P4 P3 P2 P1 P0
- _
- .T&
- cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
- V.110 V.120 X.30 X.31 res. res. res. res. | ua\d\u)\d
- .TE
- .LP
- Example:\ 11000000 supports V.110 and V.120 protocols.
- .LP
- \fINote\fR
- \ \(em\ Bits marked \*Qres.\*U are set to 0, pending
- future allocation.
- .LP
- \ua\d\u)\d\ Use of P0 as an extension bit is for further
- study.
- .LP
- FIGURE\ I\(hy5/I.515
- \fBPI interpretation\fR
- .nr PS 9
- .RT
- .ad r
- \fBFigure I\(hy5/I.515 (comme tableau) [T2.515], p. 23\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- After the answering end has sent its PI, it sends a distinct \*Qidle byte\*U
- (see Figure\ I\(hy6/I.515) continuous and waits for the matching PI from
- the originating end.
- .ce
- \fBH.T. [T3.515]\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | lw(48p) .
- B1 B2 B3 B4 B5 B6 B7 B8
- _
- .T&
- cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) .
- 0 1 1 1 1 1 1 1 (7F in hexadecimal)
- .TE
- .LP
- \fINote\ 1\fR
- \ \(em\ B1 is transmitted and received first.
- .LP
- \fINote\ 2\fR
- \ \(em\ B8 is set to 1 for transmission and ignored
- on reception.
- .LP
- FIGURE I\(hy6/I.515
- \fBIdle byte\fR
- .nr PS 9
- .RT
- .ad r
- \fBFigure I\(hy6/I.515 (comme tableau) [T3.515], p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .PP
- The originating end then sends back its PI with only the bit that corresponds
- to the desired TA protocol set to\ 1.
- .PP
- If the originating end cannot support any of the answering end's TA
- protocols, it sends back a null PI byte (Figure\ I\(hy7/I.515), and then
- terminates the call using normal call disconnection procedures.
- .RT
- .ce
- \fBH.T. [T4.515]\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | lw(48p) .
- P0 P1 P2 P3 P4 P5 P6 P7
- _
- .T&
- cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) .
- 0 0 0 0 0 0 0 0 {
- (00 in hexadecimal)
- FIGURE\ I\(hy7/I.515
- \fBNull PI byte\fR
- }
- _
- .TE
- .nr PS 9
- .RT
- .ad r
- \fBFigure I\(hy7/I.515 (comme tableau) [T4.515], p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- The method described in this section:
- .LP
- a)
- supports various CCITT recognized forms of TA
- schemes;
- .LP
- b)
- allows for future TA schemes;
- .LP
- c)
- limits the proliferation of TA schemes;
- .LP
- d)
- allows the originating end to control the selection of the
- common TA protocol; and
- .LP
- e)
- provides a positive indication of a failed
- call.
- .ce 1000
- APPENDIX\ II
- .ce 0
- .ce 1000
- (to Recommendation I.515)
- .sp 9p
- .RT
- .ce 0
- .ce 1000
- \fBTA protocol self identification\fR
- .sp 1P
- .RT
- .ce 0
- .PP
- This appendix discusses guidelines for self\(hyidentification
- procedures that may be used by multi\(hyprotocol terminal adaptor (MTA)
- implementations in selecting the protocol to be used on an individual
- connection. It is assumed that the multi\(hyprotocol terminal adaptor supports
- the procedures of Recs.\ I.463 (V.110) and I.465\ (V.120). Where out\(hyband
- signalling is available, multi\(hyprotocol terminal adaptors should function
- in accordance
- with the protocol negotiated during call set\(hyup. Self\(hyidentification
- procedures are only applicable where such signalling capabilities are not
- available.
- .sp 1P
- .RT
- .sp 1P
- .LP
- II.1
- \fIMTAs intended to interwork with uni\(hyprotocol TAs\fR
- .sp 9p
- .RT
- .PP
- The MTA may initiate transmission as if it were a uni\(hyprotocol TA conforming
- to any of the capabilities provided. The received signals would be examined
- by the MTA and the MTA should revert to transmission in accordance
- with the procedures of the protocol of the uni\(hyprotocol TA as indicated
- by the received signals. If compatibility is not achieved it would provide
- a
- disconnect.
- .PP
- It is noted that there is a range of capabilities that may be
- implemented in TAs conforming to either Rec.\ I.463 (V.110) or Rec.\ I.465
- (V.120). For distinguishing the capabilities of the different TA protocols,
- an MTA should follow the procedures specified in the individual
- Recommendations.
- .RT
- .sp 1P
- .LP
- II.2
- \fIMTAs intended to interwork with other MTAs\fR
- .sp 9p
- .RT
- .PP
- The MTA should initiate transmission, following the connect
- indication, in accordance with Rec.\ I.465\ (V.120).
- .PP
- \fINote\fR \ \(em\ Self identification can be extended to accommodate multiple
- protocols. It is only necessry to define the priority for the use of each
- protocol and a retry procedure. The general rule would be that an MTA would
- always initiate transmission assuming the protocol of the highest priority
- suported that has not been tried. The MTA would always delay disconnect,
- when the received signal is not recognized, for a period long enough for
- the
- necessary number of retries [this is protocol and implementation
- dependent\ \(em\ see, for example, Recs.\ I.463 (V.110) and
- I.465\ (V.120)].
- .bp
- .RT
- .ce 1000
- APPENDIX\ III
- .ce 0
- .ce 1000
- (to Recommendation I.515)
- .sp 9p
- .RT
- .ce 0
- .ce 1000
- \fBParameter exchange for selection of IWFs\fR
- .sp 1P
- .RT
- .ce 0
- .ce 1000
- \fBin the case of ISDN\(hyPSTN data interworking\fR
- .ce 0
- .LP
- III.1
- \fIMechanisms for modem selection\ \(em\ General options\fR
- .sp 1P
- .RT
- .PP
- The IWF would have to cooperate with the user to establish the
- appropriate modem selection. The interworking function may also be required
- to convert the signalling format, and negotiate the required data signalling
- rate (modem rate).
- .PP
- There are two general categories of modem selection
- techniques:
- .RT
- .LP
- a)
- mechanisms which do not require the ISDN user to have prior\fR knowledge
- of the modem characteristics of the PSTN
- user;
- .LP
- b)
- mechanisms which may require the ISDN user to have prior\fR knowledge
- of the modem characteristics of the PSTN
- user.
- .PP
- \fINote\fR \ \(em\ The preferred methods for modem selection for ISDN\(hyPSTN
- calls are for further study.
- .sp 2P
- .LP
- III.1.1
- \fIMechanisms which do not require the ISDN user to have prior\fR \fIknowledge
- of the modem characteristics of the PSTN user\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- III.1.1.1
- \fIUse of a multi\(hystandard modem at the IWF\fR
- .sp 9p
- .RT
- .PP
- The modem in the IWF recognizes and adapts to the end\(hyuser
- modulation standard. The number of, and choices of, modulation standards
- that would be supported in the IWF is for further study and would normally
- be a
- service provider option. For examples of possible implementation see
- Recs.\ V.100 and\ V.32.
- .RT
- .sp 1P
- .LP
- III.1.1.2
- \fINegotiation\fR
- .sp 9p
- .RT
- .PP
- Negotiation between end\(hyuser and network or between networks or
- between users to determine compatible modem characteristics may be possible
- where suitable signalling methods exist. The signalling capabilities and
- parameters required are for further study, and would normally be a service
- provider option.
- .RT
- .sp 1P
- .LP
- III.1.1.3
- \fIRegistration\fR
- .sp 9p
- .RT
- .PP
- The DTE/DCE characteristics of the PSTN user are registered with
- the ISDN.
- .RT
- .sp 2P
- .LP
- III.1.2
- \fIMechanisms which may require the ISDN user to have prior\fR
- \fIknowledge of modem characteristics of the PSTN user\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- III.1.2.1
- \fIDefault identification\fR
- .sp 9p
- .RT
- .PP
- Any DTE uses the same default modem characteristics.
- .RT
- .sp 1P
- .LP
- III.1.2.2
- \fISelection by ISDN user of the modem dynamically\fR
- .sp 9p
- .RT
- .PP
- Using available parameter exchange mechanisms (i.e. SN,
- LLC/BC, IPE) the user selects specific TA/modem characteristics at
- the\ IWF.
- .RT
- .sp 2P
- .LP
- III.2
- \fIISDN bearer capabilities for interworking\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- III.2.1
- \fI3.1 kHz ISDN bearer capability\fR
- .sp 9p
- .RT
- .PP
- See Figure III\(hy1/I.515.
- .PP
- In the scenario the following cases are considered:
- .RT
- .LP
- \(em
- terminal is connected to ISDN access via a modem and uses a
- 3.1\ kHz audio bearer through TA;
- .LP
- \(em
- terminal selection in ISDN is made by means of multiple
- subscribers numbers.
- .bp
- .PP
- The PSTN user uses only the number corresponding to the
- appropriate terminal in ISDN for a call to that terminal. ISDN user does the
- same for calls to other terminals in ISDN or PSTN.
- .LP
- .rs
- .sp 8P
- .ad r
- \fBFigure III\(hy1/I.515, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- III.2.2
- \fI64 kbit/s ISDN bearer capability\fR
- .sp 9p
- .RT
- .PP
- The following modem selection procedures apply to ISDN\(hyPSTN
- interworking (see Figure\ III\(hy2/I.515) since the ISDN and PSTN will share
- network transmission and switching facilities. These modem selection procedures
- assume that the modem interworking point will be the originating (for ISDN
- to PSTN calls) or terminating (for PSTN to ISDN calls) ISDN exchange, i.e.
- modem pools are available at each ISDN exchange.
- .PP
- The modems in the modem pool at each ISDN exchange can be grouped
- by their speeds; suitable codes and/or full Subscriber Numbers (SNs) can
- be assigned to each group of modems.
- .RT
- .LP
- .rs
- .sp 12P
- .ad r
- \fBFigure III\(hy2/I.515, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- III.3
- \fIOptions for modem selection\fR
- .sp 9p
- .RT
- .PP
- The modem selection procedures outlined in this section are
- provided as potential options, which Administrations may choose, with
- modifications as required, to suit their own operating environment and
- applications.
- .RT
- .sp 2P
- .LP
- III.3.1
- \fIISDN\(hyPSTN calls (bidirectional)\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- III.3.1.1
- \fIOption 1 (example of the method detailed in \(sc\ III.1.1.1)\fR
- .sp 9p
- .RT
- .PP
- This is a single stage modem selection procedure which relies upon the
- following system requirements:
- .RT
- .LP
- \(em
- data terminals on the ISDN have separate SNs;
- .LP
- \(em
- the ISDN exchange can distinguish whether any incoming call
- is from the PSTN and can distinguish that an outgoing call is
- destined for the PSTN.
- .bp
- .PP
- For a voice\(hyband data call originated by a PSTN terminal, and
- intended for a data terminal on the ISDN, the terminating ISDN exchange will
- intercept the call and direct the call to an IWF. At the IWF, a modem will
- be inserted into the path, and the modem will recognize and adapt to the
- modulation standard used by the PSTN user. The IWF may pass parameters
- (e.g.\ LLC) to the called user when establishing the ISDN portion of
- the call.
- .PP
- For a data call originated in the ISDN intended for a data terminal
- on the PSTN, the ISDN exchange will intercept the call and direct the call
- to the IWF. The IWF will use the requested service (BC/LLC) on the ISDN
- portion
- of the call. At the IWF, a modem will be inserted into the path, and the
- modem will recognize and adapt to the modulation standard used by the
- PSTN user.
- .RT
- .sp 1P
- .LP
- III.3.1.2
- \fIOption 2 (example of the method detailed in III.1.1.3)\fR
- .sp 9p
- .RT
- .PP
- This is a single stage modem selection procedure which relies on
- the following system requirements:
- .RT
- .LP
- \(em
- circuit data terminals on ISDN loops have
- separate SNs;
- .LP
- \(em
- a call progress indicator that PSTN to ISDN, or ISDN to PSTN
- interworking has occurred; and
- .LP
- \(em
- service profiles of destination terminals are available at
- the ISDN exchange (data \fIvs\fR speech terminals, pre\(hysubscribed
- modem type).
- .sp 1P
- .LP
- III.3.1.2.1
- \fIPSTN\(hyto\(hyISDN call\fR
- .sp 9p
- .RT
- .PP
- The terminating ISDN exchange recognizes that:
- .RT
- .LP
- \(em
- the call is from the PSTN (from the call progress
- indicator);
- .LP
- \(em
- the call is for a data terminal (from service profile);
- and
- .LP
- \(em
- the modem type subscribed to (from service
- profile).
- .PP
- The terminating exchange will insert the pre\(hysubscribed modem
- type from the pool.
- .sp 1P
- .LP
- III.3.1.2.2
- \fIISDN\(hyto\(hyPSTN call\fR
- .sp 9p
- .RT
- .PP
- The ISDN terminal will initiate the callas a 64\ kbit/s, rate
- adapted digital data call for all calls to both ISDN and PSTN destinations.
- On the receipt of the progress indicator (ISDN/PSTN interworking), the local
- exchange will insert the pre\(hysubscribed modem type in the path.
- .PP
- If the calling ISDN terminal knows \fIa priori\fR | that the called
- terminal in on a PSTN analogue loop, it may indicate in the \fIset\(hyup\fR
- message
- the pre\(hysubscribed modem type to be inserted.
- .RT
- .sp 2P
- .LP
- III.3.2
- \fIISDN\(hyto\(hyPSTN calls\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- III.3.2.1
- \fIOption 3 (example of the method detailed in III.1.2.2)\fR
- .sp 9p
- .RT
- .PP
- For a data call originated by a data terminal on the ISDN, the
- modem selection is done by using some appropriate information elements
- in the Q.931 \fIset\(hyup\fR message. Modem selection by the calling party
- is dependent upon the calling party's prior knowledge of the modulation
- standard used by the
- called party on the PSTN or upon the user of a multi\(hystandard modem
- at the IWF. The appropriate modem is inserted in the end\(hyto\(hyend path.
- .RT
- .sp 2P
- .LP
- III.3.3
- \fIPSTN\(hyto\(hyISDN calls\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- III.3.3.1
- \fIOption 4 (example of the method detailed in III.1.2.2 using\fR \fIsubscriber
- number.)\fR
- .sp 9p
- .RT
- .PP
- This is a two\(hystage method in which the modem pools at each
- exchange are grouped according to modulation standard and/or speed and each
- group is assigned a full subscriber number\ (SN). The first stage selects an
- appropriate modem and the second stage completes the connection to the
- desired terminal through the selected modem. Separate SNs for the data
- terminals on the ISDN digital loop are not needed because it is the responsibility
- of the PSTN subscriber to request a modem from the pool when he needs a
- data connection;
- the IWF will generate the appropriate bearer capability. However, the PSTN
- terminal equipment should have the capability to input a second set of
- digits, i.e.\ the called number (e.g. using V.25 | fIbis\fR protocol).
- .bp
- .PP
- Therefore for a PSTN\(hyto\(hyISDN data call, the PSTN user first dials
- the address of the appropriate group of modems at the terminating exchange.
- Once
- this connection is established the PSTN user dials the address of the called
- ISDN subscriber. This set of digits is used by the signalling conversion
- functionality (part of the IWF at the terminating exchange) to set\ up the
- connection from the modem to the called ISDN terminal. The exchange of call
- progress tones for this case needs further study.
- .RT
- .sp 1P
- .LP
- III.3.3.2
- \fIOption 5 (example of the method detailed in III.1.1.2)\fR
- .sp 9p
- .RT
- .PP
- This is a single\(hystage modem selection procedure which relies upon the
- following system requirements:
- .RT
- .LP
- \(em
- circuit data terminals on ISDN loops have separate SNs;
- .LP
- \(em
- PSTN terminals have suitable signalling capabilities to
- indicate the modem speed/type in response to a request from
- the terminating exchange;
- .LP
- \(em
- the ISDN exchange can distinguish whether an incoming call is
- from the PSTN or the ISDN (using call progress indicator);
- and
- .LP
- \(em
- the ISDN exchange maintains a data base on service profiles
- of terminals served by the exchange (analog\ \fIvs\fR digital,
- and speech\ \fIvs\fR data in case of digital
- subscribers).
- .PP
- The user must be aware of any special operational
- requirements.
- .PP
- For a voice\(hyband data call originated by a PSTN terminal, and intended
- for a digital data terminal on the ISDN, the terminating ISDN exchange
- will
- recognize that:
- .RT
- .LP
- \(em
- the call is coming from the PSTN; and
- .LP
- \(em
- the call is intended for a digital data terminal on the
- ISDN.
- .PP
- The terminating ISDN exchange will intercept the call and send a suitable
- tone/signal back to the originating PSTN subscriber. Using some
- suitable signalling capability, the PSTN subscriber will indicate the code
- for modem selection, which will be used by the terminating exchange to
- attach a
- suitable modem and complete the path to the digital data terminal.
- .LP
- .rs
- .sp 27P
- .sp 2P
- .LP
- \fBMONTAGE: RECOMMANDATION I.520 SUR LE RESTE DE CETTE PAGE\fR
- .sp 1P
- .RT
- .LP
- .bp
-