Information technology — Telecommunications and information exchange between systems — Private Integrated Services Network — Architecture and Scenarios for Private Integrated Services Networking

Concerns with Private Integrated Service Networks (PISNs) comprising one or more than one PISN exchanges (PINX) interconnected by inter-PINX connections (IPCs). Specifies unter-PINX connections that are provided by intervening networks (IVNs), and the way in which these are handled by PINXs to provide a platform for inter-PINX communication. Identifies the standardization to inter-connect PINXs and general techniques, procedures and protocolls for all types of IVNs.

Technologies de l'information — Télécommunications et échange d'information entre systèmes — Réseau privé à intégration de services — Architecture et scénarios pour réseau privé à intégration de services

General Information

Status
Withdrawn
Publication Date
17-Apr-1996
Withdrawal Date
17-Apr-1996
Current Stage
9599 - Withdrawal of International Standard
Completion Date
10-Jul-2001
Ref Project

Relations

Buy Standard

Technical report
ISO/IEC TR 14475:1996 - Information technology -- Telecommunications and information exchange between systems -- Private Integrated Services Network -- Architecture and Scenarios for Private Integrated Services Networking
English language
19 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

TECHNICAL ISOAEC
REPORT
TR 14475
First edition
1996-05-01
Information technology -
Telecommunications and information
exchange between systems - Private
Integrated Services Network -
Architecture and Scenarios for Private
Integrated Services Networking
Technologies de /‘information - TMcommunica tions et khange
d’information entr-e systirmes - R&eau pri& ;> integration de services -
Architecture et sbnarios pour r-beau priv6 P integration de services
Reference number
ISO/I EC TR 14475: I 996(E)

---------------------- Page: 1 ----------------------
ISO/IEC TR 14475:1996(E)
Contents
1
Scope
1
1
2 References
2
Definitions
2
External Definitions
31 .
2
32 . Special Definitions
2
3.2.1 Scenario
2
3.2.2 Inter-PINX Connection (IPC)
2
Inter-PINX Link (IPL)
3.2.3
2
3.2.4 Channel
2
3.2.4.1 DQ-Channel
3
3.2.4.2 UQ-Channel
3
3.2.4.3 DC-Channel
(IS-
3.2.4.4 IPL-Setvice-Channel
Channel)
3.25 Signalling Functions
3.2.5.1 CSIG
3.2.5.2 QSIG
3.2.5.3 TSIG
3.2.5.4 ScenSlG
4 Symbols and Abbreviations
4
5 Introduction
4
5.1 PINX Reference Configuration
5
52 . Additional Descriptions
5
5.2.1 Inter-PINX Connection (IPC)
6
Inter-PINX Link (IPL)
5.2.2
6
5.2.2.1 IPL Identity
6
5.2.2.2 Channel Identity
6
5.2.2.3 Channel Usage
6
5.2.2.4 Channel Characteristics
6
5.2.3 Relationship between IPLs and IPCs
0 lSO/lEC 1996
All rights reserved. Unless otherwise specified, no part of this publication may be
reproduced or utilized in any form or by any means, electronic or mechanical, including
photocopying and microfilm, without permission in writing from the publisher.
lSO/IEC Copyright Office l Case postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii

---------------------- Page: 2 ----------------------
@ lSO/IEC ISO/IEC TR 14475: 1996(E)
6 Details of the Functional Groupings as Relevant for Scenario
7
Handling
Mapping Unit (MP) 7
61 .
6.1.1 Physical Adaptation 7
6.1.2 Mapping Matrix 7
Inter-PINX Connection Control (ICC)
6.2 8
6.2.1 IPC Control
8
6.2.2 IPL Control
8
Scenario Management
6.3 9
6.3.1 Link Resource Management
9
6.3.2 Mapping Management
9
6.3.3 IPC Management
10
6.4 Complete PINX Model 10
7 Configuration Variants 10
7.1 PINX with Multiple IPLs 11
7.2 More than One Type of IVN 11
7.3 Different Spread of IPCs among the Interfaces at the
Two PlNXs 11
a IPL Establishment using ScenSlG 12
81 Static Pre-Conditions
12
8:2 Establishment of a First IPC 13
8.3 IPL Initialization Process 13
84 . Establishment of the D&Channel
13
8.4.1 DQ-Channel and ScenSlG on the First IPC 13
8.4.2 DQ-Channel and ScenSlG on another IPC
13
85 Establishment of UQ-Channels 14
8:6 Channel Mapping 14
9 IPL Establishment Procedures without using ScenSlG 14
91 . Static Pre-Conditions 15
92 . Establishment of a First IPC 15
Establishment of the DQ-Channel 15
93
. Establishment of UQ-Channels 15
9’4
1 0. IPL Administration Procedures 15
Items for Future Standardization 15
1 1
Static Pre-Conditions 15
11.1
IVN Bearer Capabilities 16
11.2
Physical Adaptation 16
11.3
Conditioning 16
1 1.4 Mapping Matrix, including Bearer
16
11.5 IPC Establishment
16
11.6 ScenSlG
17
Annex A: Attribute Values

---------------------- Page: 3 ----------------------
ISO/IEC TR 14475: 1996(E) 0 ISO/lEC
Foreword
IS0 (the International Organization for Standardization) and IEC (the
lnte national Electrotechnical Commission) form the specialized system for
wor dwide standardization. National bodies that are members of IS0 or
IEC participate in the development of International Standards through
ted nical committees established by the respective organization to deal
with particular fields of technical activity. IS0 and IEC technical
committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with IS0 and
IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical committee, lSO/l EC ITC 1.
The main task of technica committees is to prepare International
Standards, but in exceptional circumstances a technical committee may
propose the publication of a Technical Report of one of the following
types:
required support cannot be obtained
type 1, when the for the
publication of an lnte rnational repeated effo
Standard, despite rts;
- type 2, when the subject is still under technical development or
where for any other reason there is the future but not immediate
possibility of an agreement on an International Standard;
- type 3, when a technical committee has collected data of a different
kind from that which is normally published as an International
Standard (“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three
years of publication, to decide whether they can be transformed into
International Standards. Technical Reports of type 3 do not necessarily
have to be reviewed until the data they provide are considered to be no
longer valid or useful.
lSO/IEC TR 14475, which is a Technical Report of type 3, was prepared by
Joint Technical Committee lSO/lEC JTC 1, Information technology,
Subcommittee SC 6, Telecommunications and information exchange
between systems.

---------------------- Page: 4 ----------------------
TECHNICAL REPORT @ lSO/IEC
ISO/lEC TR 14475: 1996(E)
Information technology - Telecommunications and
information exchange between systems - Private
Integrated Services Network - Architecture and
Scenarios for Private Integrated Services Networking
1 Scope
A Private Integrated Service Network (PISN) is a network comprising either one PINX or more than
one PINX interconnected by Inter-PINX connections. This Technical Report is concerned with
inter-PINX connections (IPC) that are provided by Intervening Networks (IVN), and the way in
which these are handled by PINXs to provide a platform for inter-PINX communication. Different
types of IVNs can be used to provide IPCs, in accordance with the scenarios indicated in [l].
These are Overlay Scenarios in that they enable the services of the PISN to operate transparently
across an IVN.
Connected PlNXs need to coordinate their use of IVNs, and appropriate standardization is
needed to allow networks to be created employing PlNXs and IVNs from multiple vendors. The
following points need to be considered:
1. In general but depending on the type of IVN, procedures and signalling protocols between
the PlNXs are needed for the establishment, maintenance and disestablishment of IPCs.
Appropriate standardization of these procedures and signalling protocols is necessary.
At the Q-reference point (a conceptual point within a PINX) channels and PISN call control
2.
signalling (QSIG) are defined independently of the type of IVN.
However, at the C-reference point (where the PINX is connected to the IVN), the
representation of the channels and of signalling is dependent on the type of IVN, and on how
the PINXs use the IPCs. Appropriate standardization of these aspects at the C reference point
is necessary.
In general the relationship between a channel at the Q-reference point and its representation
3 .
at the C-reference point is not static, and procedures and signalling between the PlNXs are
needed for the coordination of these relationships. Appropriate standardization of these
procedures and signalling is necessary.
Appropriate mechanisms need to be standardized for conveying inter-PINX signalling through
4.
the IVN. These will depend on the characteristics of the IPC used.
The aim of this Technical Report is to identify:
1. in addition to PISN call control signalling (QSIG), what needs to be standardized, in order to be
able to inter-connect PINXs;
2. techniques, procedures, protocols etc. that are general in that they apply to the use of all (or
at least very many) types of IVNs.
2 References
ISO/IEC 11579-l :I 994, Information technology - Telecommunication and information exchange
between systems - Private integrated service network - Part I: Reference configuration for
PISN Exchanges (PINX).
ISO/I EC 7776: 1995, Information technology - Telecommunications and information exchange
between systems - High-level data link control procedures - Description of the X.25 LAPB-com-
pa tible DTE data link procedures.
1

---------------------- Page: 5 ----------------------
0 lSO/IEC
ISO/IEC TR 14475: 1996(E)
ITU-T Rec. I. 140( 1994), Attribute technique for the characterization of telecommunication services
supported by an ISDN and netwrok capabilities of an ISDN (Blue Book).
ITU-T Rec. 1.112(1993), Vocabulary of terms for ISDN (Blue Book).
ITU-T Rec. 1.210(1993), Principles of telecommunication services supported by an ISDN and
means to describe them (Blue Book).
ITU-T Rec. 1.41 I(1 993), ISDN user-network interfaces - Reference configurations (Blue Book).
Definitions
3
For the purposes of this Technical Report the following definitions apply.
3.1 External Definitions
This Technical Report uses the following terms defined in other documents:
Basic Service (ITU-T Rec. 1.210)
(ISOAEC 11579-l)
Private Integrated Services Network (PISN)
Private Integrated Services Network Exchange (PINX) (ISOAEC 11579-l )
Service (ITU-T Rec. 1.112)
Signalling (ITU-T Rec. 1.112)
(ITU-T Rec. 1.210)
Supplementary Service
Supplementary Service Control Entity (ISOAEC 11582)
(ISOAEC 11572)
Terminating PINX
(ISOAEC 11572)
Transit PINX
User (ISOAEC 11574)
3.2 Special Definitions
3.2.1 Scenario
A particular type of IPC provided by a particular type of IVN.
3.2.2 Inter-PINX Connection (IPC)
A connection provided by an IVN between two C reference points used to transport inter-PINX
information from the PISN control plane and/or the PISN user plane.
3.2.3 Inter-PINX Link (IPL)
A link between the Q reference points of two PINXs, comprising the totality of signalling transfer
and user information transfer means.
Channel
3.2.4
A means of bi-directional transmission of user or signalling information between two points.
3.2.4.1 D&hannel
A channel used to convey call control information between the Q reference points of two peer
PINXs.
NOTE - Call control information can include information for the control of basic services,
supplementary services, additional network features, etc.

---------------------- Page: 6 ----------------------
0 lSO/lEC ISO/IEC TR 14475: 1996(E)
3.2.4.2 U,-Channel
A channel used to convey user information between the Q reference points of two PINXs.
3.2.4.3 D&hannel
A channel used to convey lPC control information, at the C reference point, between a PINX and
an IVN.
NOTE - This does not preclude the conveyance of other types of information.
3.2.4.4 IPL-Service-Channel (IS-Channel)
A channel used to convey information related to the management of scenarios between the two
peer PINXs.
NOTE - This channel conveys ScenSIG. The use for other applications is outside the
scope of this Technical Report.
3.2.5 Signalling Functions
3.2.5.1 CSIG
The generic term describing access signalling information flows (i.e. not a specific signalling pro-
tocol) between a PINX and an IVN, at the C reference point.
3.2.5.2 QSIG
The generic term describing the signalling information flows (i.e. not a specific signalling protocol),
within a Do-channel.
3.2.5.3 TSIG
The generic term describing signalling information flows (i.e. not a specific signalling protocol) for
interworking between a PINX and the public ISDN (which occurs at the T reference point).
3.2.5.4 ScenSIG
The generic term describing the signalling information flows (i.e. not a specific signalling protocol)
supporting the handling of the specific scenario employed between the two interconnected
PINXs.
4 Symbols and Abbreviations
Availability Check Procedure
ACP
C reference point
C
Instance i of a C reference point
C
i
Channel
Ch
Call Control functional grouping
cc
Calling Line Identification Presentation
CLIP
Circuit Mode
CM
Connected Line Identification Presentation
COLP
SIGnaIling information flows at the C reference point
CSIG
CUG Closed User Group
Direct Dial In
DDI
High Layer Compatibility
HLC
ICC Inter-PINX Connection (IPC) Control functional grouping
Id Identity
3

---------------------- Page: 7 ----------------------
lSO/IEC TR 14475: 1996(E)
0 lSO/lEC
IFC InterFaCe
IPC Inter-PINX Connection
IPL Inter-PINX Link
IPL Service
IS
IVN Intervening Network
LLC Low Layer Compatibility
MC Mapping Control
MP Mapping functional grouping
NP Numbering Plan
PSPDN Packet Switched Public Data Network
PISN Private Integrated Service Network
PINX Private Integrated Network Exchange
PM Packet Mode
Q reference point
Q
Instance i of a Q reference point
Q
i
QSIG SIGnaIling information flows at the Q reference point
ScenSlG Scenario SIGnaIling information flows
SS#7 Signalling System No. 7
Switching functional grouping
SW
T T reference point
SIGnaIling information flows at the T reference point
TSIG
5 Introduction
Some general mapping functions are listed in the reference configuration for PINXs, defined in
ISOAEC 11579-I. Further definitions are required to understand the cooperation of functions in a
PINX, to derive from them a subset which needs to be standardized.
Subclause 5.1 provides an excerpt from those functions mentioned in ISOAEC 11579-l which
are relevant to this document. Subclause 5.2 and its subclauses describe refinements of these
functions and some additions necessary for understanding the overall context,
5.1 PINX Reference Configuration
Figure 1 shows an excerpt from the PINX reference configuration as described in
ISOAEC 11579-l.
PINX
C
C
I I
I I
-
I IVN
m Mapping
Switching
I \
I
II
I-
ICC
cc
I I
Scenario Management
I I I
Figure 1 - PINX Reference Configuration (Excerpt)

---------------------- Page: 8 ----------------------
@ lSO/IEC ISO/IEC TR 14475: 1996(E)
Depending on the topology of a particular PISN, a PINX may in practice have links with several
other PlNXs and may also have more than one link with the same PINX, i.e. more than one
inter-PINX link may be present on a particular PINX. A PINX will then have an instance of the
Q reference point (Q1 l a. Q,) for each IPL. This is not shown in Figure 1 (and also not in
subsequent figures).
For the purpose of this Technical Report, the key aspects derived from [l] are:
- Mapping Functional Grouping (MP)
The MP provides the functions which are necessary to adapt to physical, electrical and
procedural conditions of the interface between the PINX and the IVN. MP also provides
the multiplexing functions which are required to separate or merge the information flows
to or from SW from or to the user plane of the IVN, and between ICC and the control plane
of the IVN.
- Switching Functional Grouping (SW)
The SW provides the switching functions for user and signalling information. Signalling
information is switched between the CC and MP.
- Call Control Functional Grouping (CC)
The CC provides the functions which are necessary to control the call and the connection
through a PISN.
- Inter-PINX Connection Control Functional Grouping (ICC)
This functional grouping provides the functions which are necessary to control the inter-
PINX connection (IPC) through the intervening network.
- Scenario Management Functional Grouping
Scenario Management coordinates the provision and use of IPCs bv:
/
- using the services of ICC to establish and release IPCs;
- using the services of ICC to liaise with the Scenario Mar
agement of the peer PINX to
agree on the use of IPCs;
- instructing MP to map Do-channels and &-channels onto I
PCs and provide any required
Bearer Conditioning.
Additional Descriptions
5.2
To apply a reference configuration to real implementations, distinction must be made between
characteristics present at the C reference point and characteristics present at the Q reference
point. To facilitate this, the following concepts are introduced:
- Inter-PINX connection (IPC); and
- Inter-PINX link (IPL).
5.2.1 Inter-PINX Connection (IPC)
An IPC is described by the attributes of the bearer service that the IVN provides. An example
attribute list is given in Annex A.
At each end an IPC is terminated at an interface at the C reference point.
NOTE I- Bearer services providing for connections that span over more than one interface
are not specifically discussed by this document.
5

---------------------- Page: 9 ----------------------
0 lSO/IEC
ISO/IEC TR 14475: 1996(E)
An interface can terminate multiple IPCs. Different IPCs terminating on the same interface can lead
to the same peer PINX or to other peer PINXs. The number of IPCs available at an interface
depends on the IVN services that the IPC uses and on the type of interface.
The types of interfaces can be different at both sides of the IVN. The IVN functionality can be
provided by multiple physical networks, of the same or of different types (e.g. ISDN at one side
and PSTN at the other side).
A PINX can have more than one interface at the C reference point.
NOTE 2 - Beside supporting the functionality specified for the C reference point, an interface
can be used for other functionality, e.g. as specified for the T reference point (shared
access use). Such use is outside the scope of this Technical Report.
5.2.2 Inter-PINX Link (IPL)
An IPL can be established between the Q reference points of two peer PINXs. More than one IPL
may be established between the same pair of PlNXs. In this case each IPL appears, at each PINX,
at a separate instance of the Q reference point.
An IPL consists of one or more channels. One of the channels (Do-channel) must be capable of
conveying PISN call control information flows (QSIG).
Further channels (Uo-channels), can be included into, or removed from, an IPL as required to
satisfy current or anticipated network traffic.
To fully describe a channel of an IPL, the following information is used:
- the IPL identity (i.e. the instance of Q reference point);
m
the channel identity (number);
- channel usage (User information, QSIG);
- the channel characteristics.
The way that IPCs are provided by the IVN may have impact on the performance and reliability of
the IPL, and on the ability of the IVN to indicate failures to the adjacent PlNXs.
5.2.2.1 IPL Identity
The IPL identity corresponds to the instance of the Q reference point. The fact that such an
instance can exist needs to be known to both PlNXs prior to IPL establishment.
5.2.2.2 Channel Identity
The channel identity is expressed by a channel number that needs to be unique within the IPL.
5.2.2.3 Channel Usage
Channel usage indicates whether a given channel is used for user information transfer or for
signalling purposes.
5 m 2.2.4 Channel Characteristics
The channel characteristics are expressed in terms of attributes, as described in Annex A.
NOTE - Channels of similar characteristics may be grouped, e.g. for routing purposes. This
is outside the scope of this Technical Report.
5.2.3 Relationship between IPLs and IPCs
The IPL appears at the Q reference point in terms of channels, and each channel is carried by
means of an IPC. An IPC can by further functions within the MP, e.g. the inclusion of multiplexing

---------------------- Page: 10 ----------------------
@ ISO/lEC ISO/IEC TR 14475: 1996(E)
and demultiplexing functions and/or splitting and merging functions, carry more or less than a
channel of an IPL (see Mapping Matrix, 6.1.2).
6 Details of the Functional Groupings as Relevant for Scenario Handling
6.1 Mapping Unit (MP)
The MP (see Figure 2) conceptually contains two subfunctions:
- physical adaptation, and
- mapping matrix.
Some of the subfunctions may be NULL in a particular implementation.
Whereas Physical Adaptation contains interface-related functionality, with regard to the C
reference point, the Mapping Matrix provides IPL-related functionality, with regard to the Q
reference point.
Both functions are described below; they can contain further subfunctions.
;Q
Interface with
._
; .,.
!u- ‘7 : __ ‘Y
multiple IPCs ’
P
g 2 “. .j !
,
P
DC
; ~~~~~~~~~~ ji ATOM&,,,,,
#
I .:.II f .:/
-!-I Mapping N latrix
‘jr ,’
;.:-‘. . . . ;.
1 ;-I;::
2 I
Interface with
a single IPCs
I
2 Other applications
&cenSlG
Figure 2 - Conceptual Infrastructure of the Mapping Functional Grouping
6.1 .l Physical Adaptation
The interface oriented Physical Adaptation function provides for the physical termination of the
IVN interface. This includes handling of the IVN-inherent management functions, e.g. as specified
for timeslot 0 of a primary rate interface, bit and frame synchronization, power feeding, etc.
If applicable, the DC-channel is added to/extracted from the interface.
6.1.2 Mapping Matrix
This function provides for the mapping of channels at the Q reference point and of the IS-
channel to the IPC(s) at the interface(s) at the C reference point (or the channels obtained by
structurization, if applicable). This can include any multiplexing/demultiplexing functions and/or
splitting/merging functions. The Mapping Matrix is under the control of the Mapping Management
function, see 6.3.2.
7

---------------------- Page: 11 ----------------------
ISO/IEC TR 14475: 1996(E) 0 lSO/IEC
If the bearer capabilities of the channels differ from those provided by the IPCs via Physical
Adaptation, Mapping Matrix will also provide Bearer Conditioning. Bearer conditioning is an
optional function.
As a further option, the settings of Bearer Conditioning can be changed (Bearer Modification). If
provided, Bearer Modification can modify any of the parameter values by which bearer capabilities
are described, see Annex A. Examples are given in Table 1:
Table 1: Examples of Attribute Changes
Attribute Change from/to . . . . Application for . . . .
Information circuit <> packet Accommodation of ScenSlG and QSIG,
Transfer Mode or packetized user data
L
A
Symmetry; unidirectional <> bi-directional disabling echo cancellation for data
symmetric transfer
Channel Rate 16 <> 32 <> 64 <> 128 <> etc. kbit/s multiplexing/demultiplexing to obtain
code conversion CL-law/A-law/ADPCM
Transfer Codina
The attribute parameters for which Bearer Conditioning is possible, and the ranges of their values,
depend on the PINX implementation.
Inter-PINX Connection Control (ICC)
6.2
The ICC provides control functions having either
- access significance, i.e. being relevant to the C reference point; or
- link significance, i.e. being relevant to the peer PINXs.
These are carried out by the subfunctions IPC Control and IPL Control respectively.
IPC Control
6.2.1
These functions control the connections at the C reference point. i.e. between the PINX and the
IVN. ICC communicates with the IVN’s control mechanism by means of the access signalling
information flows as specified for that particular type of IVN.
CSIG is used as a generic name for designating these signalling information flows.
6.2.2 IPL Control
These functions are optional and provide a communication service to Scenario Management for
interchanging IPL related information with its peer in the remote PINX. The IPL related information
flow is called ScenSIG. If it is provided, it is conveyed over an IPL Service Channel (IS).
ScenSlG is separate from the PISN call control information flows (QSIG). The communication
services provided by ScenSlG allow the following tasks to be performed:
- confirmation that the establishment of the IPC for conveying ScenSlG was successful;
- identification of either PINX to its peer;
- authentication, possibly with password exchange or encryption;
- agreement on establishing and releasing additional IPCs for the same IPL;
- agreement on establishment of the Do-channel on the same or a different IPC and any
Bearer Conditioning to be applied;
- assignment of &-channel identities, including the establishment of Bearer Conditioning,
if required to satisfy the required bearer capabilities.

---------------------- Page: 12 ----------------------
@ lSO/IEC ISO/IEC TR 14475: 1996(E)
Some of the functions listed above can also apply to an existing IPL (after the initialization pro-
cess), e.g. for adding or removing U,-channels or for changing their bearer capabilities.
6.3 Scenario Management
This function (see Figure 3) conceptually consists of three subfunctions, i.e.
- Link Resource Management;
- Mapping Management; and
- IPC Management.
Figure 3 - Scenario Management
Scenario Management performs and coordinates the Link Resource Management, the Mapping
Management and the IPC Management functions. Scenario Management evaluates requests for a
new IPL or the enhancement of an existing IPL, and decides whether an additional IPC is to be
established (IPC Management) or whether a suitable bearer capability can be obtained out of IPCs
already available (Mapping Management).
The principal function of Scenario Management is to provide channels at the Q-reference point so
that CC can select them according to users’ requests. How Scenario Management achieves this,
is outside the scope of this document.
NOTE - Basically, channel provisioning can be achieved in a forecast way, in which Scenario
Management knows in advance the peak hour traffic pattern, i.e. how many channels are
required.
Alternatively, channel provisioning can be achieved in a spontaneous way, in which
Scenario Management controls the provision of the channels on request of CC.
A more sophisticated procedure of Scenario Management could be to instruct CC to
apply a look-ahead procedure, i.e. to check (via QSIG) whether the party on PINX B is
actually available and free (e.g. does not have activated call diversion to another PINX,
and is not busy). Scenario Management will only establish the additional IPC, if the
outcome of the look-ahead procedure was positive. This procedure forms an addition to
the basic Scenario Management functions and is outside the scope of this document.
6.3.1 Link Resource Management
Link Resource Management is required whenever a PINX needs to manage scenarios
dynamically. It is responsible for ensuring the availability of an adequate number of channels with
the required bearer capabilities at the Q reference point, including updating the related data base.
As a local function, Link Resource Management is not subject to standardization.
Mapping Management
6.3.2
Mapping Management is a function with local significance at each end of the IPL. It is responsible
for activating and deactivating the individual mapping functions, e.g. for obtaining bearer
capabilities required for the channels at the Q reference point different from those available at the
interface(s) at the C reference point.

---------------------- Page: 13 ----------------------
0 lSO/IEC
ISO/IEC TR 14475: 1996(E)
Mapping Management also has mutual significance in being responsible for the end-to-end
coordination of the settings of mapping functions at the peer PINXs. This requires information to
be exchanged between their Scenario Management functional groupings. Such an exchange
can be achieved manually or by signalling means. In the latter case, ICC will then have an IPL
related control function which provides a communication service to Scenario Management. The
communication service is based on information flows between the two peer PlNXs which
generically are called ScenSIG. For the functions to be provided by the IPL related control
function see 6.2.2.
6.3.3 IPC Management
IPC Management is responsible for setting up and releasing IPCs. This function
applies to customer controllable IVN types only, e.g. a B-channel connection or a
user-user-signalling connection through a public ISDN.
6.4 Complete PINX Model
Figure 4 shows the complete PINX model composed of all individual functional groupings.
J
J
J
,
J
J
,
J
,
J
II
J
,
,
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
Bearer Conditioning
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
QSIG
&SIG &
ScenSlG
4
IPCS
Conceptual PINX Scenario Handling Functionality
Figure 4 -
10

---------------------- Page: 14 ----------------------
@ lSO/IEC
ISO/IEC TR 14475: 1996(E)
7 Configuration Variants
A number of configuration variants can occur in practice, which involve multiple instances of
certain entities, e.g.:
- a PINX has multiple IPLs, e.g. is interconnected with more than one PINX;
- more than one type of IVN exists between two PINXs;
- at each PINX the IPCs of an IVN are spread differently among the available interfaces.
These situations can occur in any combination.
7.1 PINX with Multiple IPLs
A PINX can have multiple IPLs, each terminated within the PINX at its own instance of the Q
reference points. These IPLs may lead to the same peer PINX or to different peer PINXs. Different
IPLs can be conveyed through the same or different IPCs.
An example of a PINX with two IPLs linking its 2 peer PlNXs is shown in Figure 5. The IPCs share
the same IVN. According to [l], the instances of Q reference point are marked by indexes, i.e.
Q,, Q,, Q,=
C
PINXO . c
PINXl
,
J
J
/ IVNl
Ql ,
PINX2
Figure 5 - Example of a PISN with Multiple IPLs
7.2 More than One Type of IVN
The channels of the IPL are conveyed via IPCs of different IVNs. Examples are:
- the base traffic is routed through leased lines, whereas the peak traffic between the two
PINXs is conveyed over switched connections of public ISDN equipment employed as an
IVN .
- circuit mode calls are routed through leased lines, whereas packet mode calls and QSIG
(and ScenSlG, if employed) are routed through a public s
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.