ISO/IEC TR 14475:2001

TECHNICAL ISO/IEC
REPORT TR
Second edition
2001-07-01
Information technology —
Telecommunications and information
exchange between systems — Private
Integrated Services Network —
Architecture and scenarios for Private
Integrated Services Networking
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
Reference number
©
ISO/IEC 2001
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2001
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 either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 2001 – All rights reserved

Contents Page
1 Scope 1
2 References 1
3 Terms and definitions 1
3.1 External Definitions 2
3.2 Special Definitions 2
4 Symbols and Abbreviations 4
5 Introduction 5
5.1 PINX Reference Configuration 5
5.2 Additional Descriptions 6
5.2.1 Inter-PINX Connection (IPC) 6
5.2.2 Inter-PINX Link (IPL) 6
5.2.3 Relationship between IPLs and IPCs 7
6 Details of the Functional Groupings as Relevant for Scenario
Handling 7
6.1 Mapping Unit (MP) 7
6.1.1 Physical Adaptation 8
6.1.2 Mapping Matrix 8
6.2 Inter-PINX Connection Control (ICC) 9
6.2.1 IPC Control 9
6.2.2 IPL Control 9
6.3 Scenario Management 9
6.3.1 Link Resource Management 10
6.3.2 Mapping Management 10
6.3.3 IPC Management 10
6.4 Complete PINX Model 10
7 Configuration Variants 11
7.1 PINX with Multiple IPLs 11
7.2 More than One Type of IVN 12
7.3 Different Spread of IPCs among the Interfaces at the Two PINXs12
8 IPL Establishment and administration procedures 13
8.1 IPL Establishment using ScenSIG 13
8.1.1 Static Pre-Conditions 14
8.1.2 Establishment of a First IPC 14
8.1.3 IPL Initialisation Process 14
© ISO/IEC 2001 – All rights reserved iii

8.1.4 Establishment of the D -Channel 15
Q
8.1.5 Establishment of U -Channels 15
Q
8.1.6 Channel Mapping 15
8.2 IPL Establishment Procedures without using ScenSIG 16
8.3 IPL Administration Procedures 16
9 Items for Future Standardisation 16
9.1 Mapping Function 17
9.1.1 Physical Adoption 17
9.1.2 Mapping Matrix 17
9.1.3 Static Pre-Conditions 17
9.2 ScenSIG 17
9.2.1 IPL Establishment and Administration Procedures 17
9.2.2 Bearer Modification Procedures 18
9.3 Bearer Conditioning 18
10 Scenarios 18
10.1 Scenarios: Dedicated Transmission Systems 18
10.1.1 Scenario 1.1 - Unstructured Transmission Link 18
10.1.2 Scenario 1.2 - Structured Transmission Link 19
10.2 Scenarios: Semi-Permanent IVN Connections 19
10.2.1 Scenario 2.1 - Semi-permanent Circuit Switched 19
10.2.2 Scenario 2.2 - Permanent Virtual Call 20
10.3 Scenarios: On-Demand Public Network Connections 21
10.3.1 Scenario 3.1 - On-demand Circuit Switched 21
10.3.2 Scenario 3.2 - ISDN Call with User-to-User Signalling 21
10.3.3 Scenario 3.3 - On Demand Virtual Call 22
10.4 Scenarios: Virtual Private Network 23
10.4.1 Introduction 23
10.4.2 Access Arrangements 23
10.4.3 Scenario 4.1 -Transit PINX 26
10.4.2 Scenario 4.2 -Centrex 26
10.4.3 Scenario 4.3 -Gateway to another network 27
Annexes
A - Attribute Values 28
B - Scenario 4.4 - Relay Node 30
iv © ISO/IEC 2001 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
The main task of technical 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:
� type 1, when the required support cannot be obtained for the publication of an International Standard, despite
repeated efforts;
� 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.
Technical Reports are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
Attention is drawn to the possibility that some of the elements of this Technical Report may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 14475, which is a Technical Report of type 3, was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommitee SC 6, Telecommunications and information exchange
between systems.
This second edition cancels and replaces the first edition (ISO/IEC TR 14475:1996), which has been technically
revised.
© ISO/IEC 2001 – All rights reserved v

TECHNICAL REPORT ISO/IEC TR 14475:2001(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 ISO/IEC 11579-1. These
are Overlay Scenarios in that they enable the services of the PISN to operate transparently across
an IVN.
Connected PINXs need to co-ordinate their use of IVNs, and appropriate standardisation is needed
to allow networks to be created employing PINXs and IVNs from multiple vendors. The following
points need to be considered:
� In general but depending on the type of IVN, procedures and signalling protocols between the
PINXs are needed for the establishment, maintenance and release of IPCs. Appropriate
standardisation of these procedures and signalling protocols is necessary.
� At the Q reference point (a conceptual point within a PINX) channels and PISN call control
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
standardisation 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 at
the C reference point is not static, and procedures and signalling between the PINXs are needed
for the co-ordination of these relationships. Appropriate standardisation of these procedures and
signalling is necessary.
� Appropriate mechanisms need to be standardised for conveying inter-PINX signalling through
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 standardised, in order to be
able to inter-connect PINXs;
2. General techniques, procedures, protocols etc., that apply to of all (or at least very many) types
of IVNs.
2 References
ISO/IEC 7776:1995, Information technology — Telecommunications and information exchange
between systems — High-level data link control procedures — Description of the X.25 LAPB-
compatible DTE data link procedures
ISO/IEC 11572:2000, Information technology — Telecommunications and information exchange
between systems — Private Integrated Services Network — Circuit mode bearer services —
Inter-exchange signalling procedures and protocol
© ISO/IEC 2001 – All rights reserved 1

ISO/IEC 11574:2000, Information technology — Telecommunications and information exchange
between systems — Private Integrated Services Network — Circuit-mode 64 kbit/s bearer
services — Service description, functional capabilities and information flows
ISO/IEC 11579-1:1994, Information technology — Telecommunications and information
exchange between systems — Private integrated services network — Part 1: Reference
configuration for PISN Exchanges (PINX)
ISO/IEC 11582:1995, Information technology — Telecommunications and information exchange
between systems — Private Integrated Services Network — Generic functional protocol for the
support of supplementary services — Inter-exchange signalling procedures and protocol
ITU-T Rec. I.140 (1993), Attribute technique for the characterization of telecommunication
services supported by an ISDN and network capabilities of an ISDN
ITU-T Rec. I.112 (1993), Vocabulary of terms for ISDNs
ITU-T Rec. I.130 (1988), Method for the characterization of telecommunication services
supported by an ISDN and network capabilities of an ISDN
ITU-T Rec. I.210 (1993), Principles of telecommunication services supported by an ISDN and
the means to describe them
ITU-T Rec. I.411 (1993), ISDN user-network interfaces — Reference configurations
ITU-T Rec. I.430 (1995), Basic user-network interface — Layer 1 specification
ITU-T Rec. X.31 (1995), Support of packet mode terminal equipment by an ISDN
3 Terms and definitions
For the purposes of this Technical Report the following terms and definitions apply.
3.1 External Definitions
This Technical Report uses the following terms defined in other documents:
� Basic Service (ITU-T Rec. I.210)
� Private Integrated Services Network (PISN) (ISO/IEC 11579-1)
� Private Integrated Services Network Exchange (PINX) (ISO/IEC 11579-1)
� Service (ITU-T Rec. I.112)
� Signalling (ITU-T Rec. I.112)
� Supplementary Service (ITU-T Rec. I.210)
� Supplementary Service Control Entity (ISO/IEC 11582)
� Terminating PINX (ISO/IEC 11572)
� Transit PINX (ISO/IEC 11572)
� User (ISO/IEC 11574)
3.2 Special Definitions
Attached PINX: A PINX that is attached to a VPN and capable of using VPN services.
NOTE – In the context of a call, the attached PINX can be an end-PINX (i.e. serving the originating or
destination user or acting as a gateway with another network) or it can be a transit-PINX.
2 © ISO/IEC 2001 – All rights reserved

Centrex:ThatpartofaVPNthatemulates anEnd-PINX.
Channel: A means of bi-directional transmission of user or signalling information between two points.
D -Channel: A channel used to convey IPC control information, at the C reference point, between
C
a PINX and an IVN.
NOTE - This does not preclude the conveyance of other types of information.
D -Channel: A channel used to convey call control information between the Q reference points of
Q
two peer PINXs.
NOTE - Call control information can include information for the control of basic services, supplementary
services, additional network features, etc.
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.
U -Channel: A channel used to convey user information between the Q reference points of two
Q
PINXs.
Corporate Telecommunication Network (CN):A CN consists of a set of equipment (Customer
Premises Equipment and/or Customer Premises Network) that are located at geographically
dispersed locations and are interconnected to provide networking services to a defined group of
users.
NOTE - The ownership of the equipment is not relevant to this definition.
NOTE - In this Technical Report, even equipment that is not geographically dispersed (e.g., a single PBX
or a Centrex providing service to users at a single location) may form a CN.
Interconnecting Network (ICN): The emulation of transit-PINX functionality by equipment that is
physically part of the public network infrastructure. In addition, it includes one or more IVNs and may
include the emulation of gateway-PINX functionality.
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.
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.
Relay Node (functionality): Within the context of a call the functionality that distinguishes calls
between users in the Corporate Network, and relays such calls to designated PINX functionality
emulated by public network equipment, or to an attached PINX. This may be via other relay nodes.
NOTE - Relay Node functionality includes transparent handling of private networking information (e.g.
transit counter).
Signalling Functions
CSIG: The generic term describing access signalling information flows (i.e. not a specific
signalling protocol) between a PINX and an IVN, at the C reference point.
QSIG: The generic term describing the signalling information flows (i.e. not a specific signalling
protocol), within a D -channel.
Q
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).
ScenSIG: The generic term describing the signalling information flows (i.e. not a specific signalling
protocol) that support the handling of the specific scenario employed between the two interconnected
PINXs.
© ISO/IEC 2001 – All rights reserved 3

Scenario: A particular type of IPC provided by a particular type of IVN.
Semi-permanent connection: A connection in a switched network established by the network
operator.
Virtual Private Network (VPN): Is that part of a CN that provides corporate networking using shared
switched resources from a third party provider (e.g. a public network).
4 Symbols and Abbreviations
ACP Availability Check Procedure
C C reference point
C Instance i of a C reference point
i
Ch Channel
CC Call Control functional grouping
CLIP Calling Line Identification Presentation
CM Circuit Mode
COLP Connected Line Identification Presentation
CSIG SIGnalling information flows at the C reference point
CUG Closed User Group
DDI Direct Dial In
HLC High Layer Compatibility
ICC Inter-PINX Connection (IPC) Control functional grouping
Id Identity
IFC InterFaCe
IPC Inter-PINX Connection
IPL Inter-PINX Link
IS IPL Service
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 Q reference point
4 © ISO/IEC 2001 – All rights reserved

Q Instance i of a Q reference point
i
QSIG SIGnalling information flows at the Q reference point
ScenSIG Scenario SIGnalling information flows
SS #7 Signalling System No. 7
SW SWitching functional grouping
T T reference point
TSIG SIGnalling information flows at the T reference point
5 Introduction
Some general mapping functions are listed in the reference configuration for PINXs, defined in
ISO/IEC 11579-1. Further definitions are required to understand the co-operation of functions in a
PINX, to derive from them a subset, which needs to be standardised.
Subclause 5.1 provides an excerpt from those functions mentioned in ISO/IEC 11579-1, 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 ISO/IEC 11579-1.
PINX
C
C
Q
IVN
Switching
Mapping
peer PINX
ICC
CC
Scenario Management
Figure 1 - PINX Reference Configuration (Excerpt)
Depending on the topology of a particular PISN, a PINX may in practice have links with several other
PINXs 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
(Q . Q ) for each IPL. This is not shown in Figure 1 (and also not in subsequent figures).
1 n
For the purpose of this Technical Report, the key aspects derived from ISO/IEC 11579-1 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.
© ISO/IEC 2001 – All rights reserved 5

� 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 by:
� using the services of ICC to establish and release IPCs;
� using the services of ICC to liaise with the Scenario Management of the peer PINX to agree
on the use of IPCs;
� instructing MP to map D -channels and U -channels onto IPCs and provide any required
Q Q
Bearer Conditioning.
5.2 Additional Descriptions
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 1- Bearer services providing connections that span over more than one interface are not specifically
discussed by this document.
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 - Besides 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 PINXs. In this case each IPL appears, at each PINX,
at a separate instance of the Q reference point.
6 © ISO/IEC 2001 – All rights reserved

An IPL consists of one or more channels. One of the channels (D -channel) must be capable of
Q
conveying PISN call control information flows (QSIG).
Further channels (U -channels), can be included into, or removed from, an IPL as required to satisfy
Q
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);
� 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 PINXs.
5.2.2.1 IPL Identity
The IPL identity corresponds to the instance of the Q reference point. The IPL identity needs to be
known to both PINXs prior to its establishment.
5.2.2.2 Channel Identity
The channel identity is expressed by a channel number that must 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.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
and de-multiplexing 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 sub-functions:
� physical adaptation, and
� mapping matrix.
Some of the sub-functions 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 sub-functions.
© ISO/IEC 2001 – All rights reserved 7

6.1.1 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 synchronisation, power feeding, etc.
If applicable, the D -channel is added to/extracted from the interface.
C
C
Q
Interface with
multiple IPCs
D
C
Mapping Matrix
Interface with
asingleIPCs
D
C
D
Q
Other applications
ScenSIG
Figure 2 - Conceptual Infrastructure of the Mapping Functional Grouping
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 from the structure of
the link). This can include any multiplexing/de-multiplexing functions and/or splitting/merging
functions. The Mapping Matrix is under the control of the Mapping Management function, see 6.3.2.
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 ScenSIG and QSIG,
Transfer Mode or packetized user data
Symmetry; disabling echo cancellation for data
unidirectional�
transfer
Channel Rate 16� 32� 64� 128� etc. kbit/s multiplexing/demultiplexing to obtain
higher or lower bandwidth
Information code conversionµ-law/A-law/ADPCM
Transfer Coding
The attribute parameters for which Bearer Conditioning is possible, and the ranges of their values,
depend on the PINX implementation.
8 © ISO/IEC 2001 – All rights reserved
Physical Physical
Adaptation Adaptation
6.2 Inter-PINX Connection Control (ICC)
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 sub-functions IPC Control and IPL Control respectively.
6.2.1 IPC Control
These functions control the connections at the C reference point, i.e. between the PINX and the IVN.
The ICC communicates with the IVN 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).
ScenSIG is separate from the PISN call control information flows (QSIG). The communication
services provided by ScenSIG allow the following functions to be performed:
� confirmation that the establishment of the IPC for conveying ScenSIG 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 D -channel on the same or a different IPC and any
Q
Bearer Conditioning to be applied;
� assignment of U -channel identities, including the establishment of Bearer Conditioning, if
Q
required to satisfy the required bearer capabilities.
Some of the functions listed above can also apply to an existing IPL (after the initialisation process),
e.g. for adding or removing U -channels or for changing their bearer capabilities.
Q
6.3 Scenario Management
This function (see Figure 3) conceptually consists of three sub-functions, i.e.
� Link Resource Management;
� Mapping Management; and
� IPC Management.
Link Resource
IPC Management
Mapping Management
Management
Scenario Management
Figure 3 - Scenario Management
© ISO/IEC 2001 – All rights reserved 9

Scenario Management performs and co-ordinates 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 standardisation.
6.3.2 Mapping Management
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.
Mapping Management also has mutual significance in being responsible for the end-to-end co-
ordination 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 PINXs 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
apublic ISDN.
6.4 Complete PINX Model
Figure 4 shows the complete PINX model composed of all individual functional groupings.
10 © ISO/IEC 2001 – All rights reserved

PINX
IPL
Q
Mapping Unit
C
IVN
D
C
Mapping Matrix
Switching
Bearer
Conditioning
IVN
D
Q
D
C
QSIG ScenSIG
CSIG
IPCs
IPC
IPL
CC
Control
Control
Link Resource Management Mapping Management IPC Management
Scenario Management
Figure 4 - Conceptual PINX Scenario Handling Functionality
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 PINXs is shown in Figure 5. The IPCs share
the same IVN. According to ISO/IEC 11579-1, the instances of Q reference point are marked by
indexes, Q ,Q ,Q etc.
0 1 2
© ISO/IEC 2001 – All rights reserved 11
Structurization
Structurization
Physical Physical
Adaptation
Adaptation
PINX 1
C
PINX 0
C
Q
IVN
Q
C
PINX 2
Q
Q
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 ScenSIG, if employed) are routed through a public switched packet data network
employed as an IVN.
In this case multiple instances of the C reference point relate to the single Q reference point in each
PINX. Examples of multiple instances of C reference point are given in Figure 4.
7.3 Different Spread of IPCs among the Interfaces at the Two PINXs
The way in which IPCs are spread over the interfaces available at one PINX can differ from the way
in which the IPCs are spread over the interfaces available at the peer PINX. In the case of public
ISDN equipment, even the type of interface (basic or primary rate access) may be different at the two
sides of the IVN. Except in the case of dedicated physical link or dedicated transmission systems.
Suchasituation is showninFigure6.
PINX A PINX B
C C
Q
Q
SW
SW IVN
D Channel ScenSIG D Channel
ScenSIG
Q
Q
Interfaces
Figure 6 - Different Interfaces at either Side of the IVN
In this particular example the IPCs supporting the IPL are spread over two interfaces at PINX A (one
of which carries inter-PINX signalling information), but use only one interface at PINX B.
12 © ISO/IEC 2001 – All rights reserved
Mapping
Mapping
8 IPL Establishment and administration procedures
The establishment of an IPL starts with the establishment of the underlying IPC, after which an
association between the peer PINXs will be established. This process logically corresponds to the
inauguration of the two peer instances of Q reference point.
The IPL, in general, consists of one D -channels and one or more U -channels (See 5.2.2). Thus,
Q Q
the inauguration of an IPL includes the coupling of the D -channels. This needs to occur in a
Q
synchronised manner at both sides of the IPL.
Synchronised IPL establishment can be achieved by manual intervention at either PINX or by means
of ScenSIG.
The use of ScenSIG allows all the functions listed in 6.2.2 to be performed, including those that
cannot be done by manual intervention. Not all IVN types require the use of ScenSIG. The factors
that dictate the use of ScenSIG include security, the question whether coupling is inherently given by
the IPC establishment procedure, cost, etc.
The types of IVNs that require ScenSIG needs to be determined on a case by case basis and cannot
be standardised. The following examples can be taken as models for an implementation-specific
assessment.
� A leased line-type IVN does not require ScenSIG for IPL establishment. All data required for
the inauguration process can be entered into scenario management by manual intervention.
� The UUS3-type IVN, as offered by a public ISDN, inherently provides two IPCs, one for the
exchange of inter-PINX signaling information and one for the transfer of user information. All
data required for the inauguration process are inherently given to scenario management by
the IPC establishment process.
However, if ScenSIG is not employed, care should be taken of protection against fraudulent or
incidental misuse of the PINXs' IPC ports. Establishment of such protection can be achieved, e.g., by
the use of the CLIP and/or CUG supplementary services of the IVN.
� A public ISDN-type IVN providing a variety of bearer capabilities and a flexible number of B-
channel for the exchange of inter-PINX signaling information and the transfer of user
information will, in practice, require the use of ScenSIG.
Since ScenSIG can accommodate sophisticated authentication mechanisms, enhanced
protection against fraudulent or incidental misuse of the PINXs' IPC ports can be refrained
from.
Clauses 8.1 and 8.2 describe the following IPL establishment procedures with and without the
employment of ScenSIG, in particular, for public ISDN-type IVN and lease line-type.
8.1 IPL Establishment using ScenSIG
The steps involved in establishing an IPL using ScenSIG as the means of co-ordinating the two
PINXs are:
� static pre-conditions which must be coordinated and set in both PINXs;
� the establishment of a First IPC between the two PINXs;
� the IPL initialization process;
� the establishment of a D -channel;
Q
� the establishment of U -channels.
Q
© ISO/IEC 2001 – All rights reserved 13

The PINX that initiates the establishment of an IPL is known as PINX A and the peer PINX is known
as PINX B.
8.1.1 Static Pre-Conditions
Scenario Management in PINX A and PINX B need to know the following information in advance:
� the fact that its peer does exist;
� which scenario applies to the First IPC;
� a PISN number that will cause routing to PINX B's Scenario Management;
� if applicable, supplementary services that are to be used (e.g., Subaddressing, Closed User
Group, in the case where public ISDN is employed as IVN);
� if applicable, information needed for mutual identification and authentication via ScenSIG;
� what Bearer Conditioning needs to be provided for accommodating ScenSIG;
� how many U -channels are to be established initially and through which these scenario are
Q
to be provided.
The mechanisms for providing this knowledge to Scenario Management are outside the scope of this
document.
8.1.2 Establishment of a First IPC
The Scenario Management of PINX A shall set up a basic call connection, by means of CSIG, to the
Scenario Management of its peer PINX (B).
Since IPL establishment should work even when the IVN provides only basic services, access to the
peer Scenario Management can only be achieved by a dedicated (preferably ex-directory) number of
the IVN NP.
In addition to a basic call, and if supported by the IVN, further means can be used to reach PINX B's
Scenario Management entity and/or provide mutual identification, e.g.:
� a particular LLC and/or HLC code;
� a particular subaddress;
� a particular piece of information in a User-User message;
� the CLIP and COLP supplementary services of the IVN;
� a combination of the methods above.
NOTE 1 - The types of information listed above can also provide enhanced security against accidental or
fraudulent access to the PINX management entity. The actual choice of security information, and
its possible encryption, will depend on the availability of supporting supplementary services of the
IVN. Statements on their characteristics and provision are outside the scope of this document.
The additional use of the CUG supplementary service to enhance access security to PINX B should
be studied.
NOTE 2 - If the CUG supplementary service is used in combination with the DDI supplementary service of
the IVN, both the public ISDN's and the PISN's CUG supplementary services need to be involved.
8.1.3 IPL Initialisation Process
ScenSIG is used, via the First IPC, for the confirmation that this IPC has been successfully
established. This will occur as soon as the underlying layer services are available to ScenSIG. With
14 © ISO/IEC 2001 – All rights reserved

the interchange of confirmation, and possibly identification and authentication information (see 6.2.2),
the IPL can be considered established.
8.1.4 Establishment of the D -Channel
Q
QSIG can be conveyed on the first or on another IPC.
8.1.4.1 D -Channel and ScenSIG on the First IPC
Q
The Scenario Management function of the initialising PINX indicates, via ScenSIG, which
multiplexing/de-multiplexing capability should be used for distinguishing between QSIG and
ScenSIG. QSIG can then start up between the two CCs.
8.1.4.2 D -Channel and ScenSIG on another IPC
Q
The two PINXs agree, via ScenSIG, on the establishment of a new IPC for use as a D -channel and
Q
on the Bearer Conditioning to be applied.
For any newly established IPC between the two peer PINXs special precautions must be taken
� to indicate to PINX B that the incoming setup request concerns an IPC rather than a call
setup to a PISN user (see 8.2);
� to prevent, or ensure correct handling of, collision of multiple simultaneous incoming setup
requests for IPCs which belong to different IPLs (i.e. originating from other PINXs);
� to avoid accidental or fraudulent access to PINX B's CC by non-authorized users.
The window technique should be used as a method for matching these requirements. This technique
employs the following procedure:
The initialising PINX Scenario Management function indicates (via ScenSIG) to PINX B's Scenario
Management function that it wants to establish a new IPC within the IPL already in use. PINX B
responds by returning a routing number (preferably: ex-directory) included in the IVN numbering
plan. (Other addition security enhancements, as described in 8.2 may also be used.) PINX B
during a specified time window must answer a call to this number. PINX B only accepts a call that
provides PINX A's calling identity. The calling identity can be transferred as supplementary
service information, e.g. CLIP, subaddress.
After applying the agreed Bearer Conditioning, QSIG can start up between the two CCs.
To enable QSIG to be removed from its initial IPC to another one later during the lifetime of a
scenario, ScenSIG will provide a negotiation function, so that both PINXs can agree on such later
change.
8.1.5 Establishment of U -Channels
Q
Either PINX can initialise channels independently of the direction of the initialisation of the IPL to
which the channel is to belong.
The establishment of an IPC to convey one or more U -channel follows the same procedure as
Q
specified for the D -channel, see 8.4.2. For each U -channel the two PINXs will agree, via ScenSIG,
Q
Q
on a channel number, unique within the IPL, by which the channel can be referred to by QSIG.
U -channels may be removed by agreement of the two PINXs via ScenSIG.
Q
8.1.6 Channel Mapping
At IPL level, i.e. at the Q reference point, all channels are unambiguously distinguishable.
Channels for signalling and user information transfer can be identified by mapping their identity at Q
onto a channel or timeslot identity at a particular interface at the C reference point. How this is
© ISO/IEC 2001 – All rights reserved 15

achieved, is a matter of local relevance only, and is thus left for individual implementation.
Conceptually, the PISN Scenario Management function is responsible for obtaining and memorising
the identity mapping data.
The informa
...