home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-12 | 76.9 KB | 3,344 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\ III
- \v'4P'
- .RT
- .ce 0
- .sp 1P
- .ce 1000
- \fBI.300\(hySeries Recommendations\fR \v'2P'
- .ce 0
- .sp 1P
- .ce 1000
- \fBOVERALL\ NETWORK\ ASPECTS\ AND\ FUNCTIONS\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.8\ \(em\ Rec.\ I.310''
- .OF '''Fascicle\ III.8\ \(em\ Rec.\ I.310 %'
- .LP
- .bp
- .sp 1P
- .ce 1000
- \v'3P'
- SECTION\ 1
- .ce 0
- .sp 1P
- .ce 1000
- \fBNETWORK\ FUNCTIONAL\ PRINCIPLES\fR \v'6p'
- .ce 0
- .sp 1P
- .sp 2P
- .LP
- \fBRecommendation\ I.310\fR
- .RT
- .sp 2P
- .sp 1P
- .ce 1000
- \fBISDN\ \(em\ NETWORK\ FUNCTIONAL\ PRINCIPLES\fR
- .EF '% Fascicle\ III.8\ \(em\ Rec.\ I.310''
- .OF '''Fascicle\ III.8\ \(em\ Rec.\ I.310 %'
- .ce 0
- .sp 1P
- .ce 1000
- \fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR
- .sp 9p
- .RT
- .ce 0
- .sp 1P
- .LP
- \fB1\fR \fBGeneral\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 1.1
- \fIBasic philosophy of the functional description\fR
- .sp 9p
- .RT
- .PP
- The objective of this Recommendation is to provide a common
- understanding of the ISDN capabilities, including terminal, network and
- specialized service centre aspects.
- .PP
- A functional description of ISDN capabilities must allow a clear
- distinction between definition/specification aspects of services provided by
- the ISDN and the actual specification of the equipment utilized to support
- those services. Therefore, an implementation\(hyindependent approach should be
- adopted.
- .PP
- Moreover in the context of this Recommendation the adjective
- \*Qfunctional\*U is used in the sense of an implementation\(hyindependent
- approach.
- The noun \*Qfunction\*U itself has a specific meaning which is explained
- below.
- .PP
- The description of network capabilities is consistent with the
- protocol reference mode, e.g.:
- .RT
- .LP
- \(em
- the layering structure of all systems involved in a
- communication process, i.e.\ partitioning the required functions between
- different layers;
- .LP
- \(em
- the clear discrimination between layer service concept, layer function
- concept and layer protocol concept.
- .PP
- Furthermore, the three following distinctions apply:
- .LP
- \(em
- distinction between basic services and supplementary
- services;
- .LP
- \(em
- distinction between ISDN capabilities and services offered to the customer;
- .LP
- \(em
- distinction between static and dynamic aspects of the
- description.
- .sp 1P
- .LP
- 1.2
- \fIServices supported by an ISDN\fR
- .sp 9p
- .RT
- .PP
- The concepts and the principles of an ISDN are described in
- Recommendation\ I.120. The services supported by an ISDN are given in the
- I.200\(hySeries of Recommendations. A classification and the tools for the
- description of telecommunication services are specified in Recommendation\
- I.210 according to the description method as given in Recommendation\ I.130.
- The
- network capabilities to support these services are defined in the I.300\(hySeries
- of Recommendations. The relationship between these Recommendations and
- some
- other relevant I\(hySeries Recommendations is shown in
- Figure\ 1/I.310.
- .bp
- .RT
- .LP
- .rs
- .sp 22P
- .ad r
- \fBFigure 1/I.310, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- It should be noted that the service concept defined in
- Recommendation\ I.210 is different from the layer service concept of the
- OSI\ model. The telecommunication service concept in Recommendation\ I.210
- corresponds to the services offered to users by the network. Besides
- operational and commercial aspects, the provision of these telecommunication
- services (bearer and teleservices) and associated supplementary services
- requires the availability of appropriate capabilities:
- .LP
- \(em
- network capabilities, in various network equipments
- (exchanges\ etc.);
- .LP
- \(em
- terminal capabilities;
- .LP
- \(em
- specialized service centre capabilities, when
- required.
- .sp 1P
- .LP
- 1.3
- \fIGeneric description of required capabilities\fR
- .sp 9p
- .RT
- .PP
- ISDN capabilities are the total sum of the functions required to
- support all basic and supplementary services offered by the ISDN.
- .RT
- .sp 1P
- .LP
- 1.3.1
- \fIStatic description\fR
- .sp 9p
- .RT
- .PP
- The identification and characterization of these functions, which are related
- to the specification and analysis of these basic and supplementary services,
- form the first step of the generic description. This part of the
- generic description is intrinsically static.
- .RT
- .sp 1P
- .LP
- 1.3.2
- \fIDynamic description\fR
- .sp 9p
- .RT
- .PP
- The use of a basic or supplementary service generally requires
- cooperation between functions located in different equipment.
- .PP
- The static description of the ISDN capabilities, which will be a list of
- functions, is not sufficient. It is necessary, in addition, to depict the
- sequence of events and the activation of functions coordinated by suitable
- inter\(hyequipment signals. This second step is the dynamic aspect of the
- description. This involves firstly an identification and characterization of
- the functions and then a method of showing the dynamic interaction between
- functions.
- .bp
- .RT
- .sp 2P
- .LP
- \fB2\fR \fBObjectives of the\fR
- \fBfunctional description of the ISDN\fR
- .sp 1P
- .RT
- .PP
- As described in Recommendation\ I.120, an Integrated Services
- Digital Network (ISDN) is a network providing
- end\(hyto\(hyend digital
- connectivity
- to support a wide range of telecommunication services.
- .PP
- The characterization of ISDN is centered on three main
- areas:
- .RT
- .LP
- a)
- the standardization of services offered to users, so as to enable services
- to be internationally compatible;
- .LP
- b)
- the stadardization of user\(hynetwork interfaces, so as
- to enable
- terminal equipment to be portable
- [and to assist in a)];
- .LP
- c)
- the standardization of ISDN capabilities to the degree
- necesary to allow user\(hynetwork and network\(hynetwork interworking, and thus
- achieve\ a) and\ b) above.
- .PP
- The I.200\(hySeries of Recommendations identifies the range of
- telecommunication services to be offered in an ISDN, namely bearer services,
- teleservices, and associated supplementary services and the attributes
- characterizing those services. The I.400\(hySeries of Recommendations describes
- both the functional and technical aspects of user\(hynetwork interfaces. This
- Recommendation defines the ISDN capabilities to support services via interfaces
- in terms of functions. A functional description enables a decoupling of
- services and ISDN capabilities, and therefore allows an
- implementation\(hyindependent approach.
- .PP
- The principal objectives of the ISDN functional method
- are:
- .RT
- .LP
- 1)
- to define the ISDN capabilities, by building up a harmonized set of functions
- that are necessary and sufficient to support telecommunication services
- by their static and dynamic description;
- .LP
- 2)
- to aid the evolution of ISDN capabilities (modifications,
- addition of capabilities to support new basic or supplementary services), by
- organizing this set of functions in an open\(hyended and modular structure;
- .LP
- 3)
- to aid the standardization of system\(hyindependent switching functions
- between exchanges of differing designs and manufacture;
- .LP
- 4)
- to aid the standardization of interworking standards between switching
- systems located in different countries;
- .LP
- 5)
- to provide information for the preparation of functional
- specifications for new telecommunication services;
- .LP
- 6)
- to maximize the exploitation of functions provided and
- available in switching systems.
- .PP
- The transition from an existing network to a comprehensive ISDN
- may require a period of time extending over one or more decades. Therefore
- the design of an ISDN will be revolutionary, adding capabilities in a flexible
- and modular manner. An ISDN may therefore be expected to provide an open\(hyended
- set of functional capabilities able to accommodate new needs as they arise
- at
- acceptable cost.
- .PP
- During a long intermediate period, some functions may not be
- implemented within a given ISDN. Also, specific arrangements should be
- used to ensure compatibility with existing networks and services. An ISDN
- should also give access to existing services and interwork with existing
- networks and
- terminals.
- .RT
- .sp 2P
- .LP
- \fB3\fR \fBGeneric description model\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 3.1
- \fIGeneral concepts\fR
- .sp 9p
- .RT
- .PP
- The ISDN functional description defines a set of capabilities which enable
- bearer and teleservices to be offered to users (see
- Recommendation\ I.210). The services require two different levels of ISDN
- capabilities viz.:
- .RT
- .LP
- \(em
- the low\(hylayer functions (LLF) relate to the bearer services;
- .LP
- \(em
- the high\(hylayer functions (HLF) together with the lower layer functions
- relate to the teleservices.
- .PP
- In addition, operation and maintenance capabilities are required to support
- both bearer and teleservices (see Figure\ 2/I.310).
- .bp
- .LP
- .rs
- .sp 18P
- .ad r
- \fBFigure 2/I.310, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- The capabilities of the ISDN need a detailed and rigorous
- characterization because there is a wide range of standardization issues
- involved.
- .PP
- To achieve the functional objectives described in \(sc\ 2, the ISDN
- functional description has been designed to:
- .RT
- .LP
- \(em
- define the overall functional characteristics of the
- ISDN;
- .LP
- \(em
- be implementation\(hyindependent and place no constraints on
- national network architectures beyond the network and interface standards
- given in the I\(hySeries of Recommendations;
- .LP
- \(em
- take full account of the constraints of existing dedicated
- networks;
- .LP
- \(em
- support the
- layering protocol
- concepts defined in
- Recommendation\ I.320.
- .PP
- For this purpose the concept of an
- ISDN function
- is used, which is defined as:
- .PP
- \*QA distiguishing characteristic which describes functional
- capabilities of a given equipment, or system, or network, as seen from the
- designer point of view.\*U
- .PP
- As far as possible, the number of functions should be
- limited.
- .RT
- .sp 2P
- .LP
- 3.2
- \fIStatic description model\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 3.2.1
- \fIGlobal functions (GF)\fR
- .sp 9p
- .RT
- .PP
- The description of ISDN capabilities concerns the low layers (1\(hy3) in
- a global context (see Note), i.e.\ taking into account all the equipment
- involved in the communication, according to the protocol reference model. In
- this context, a global function is defined as:
- .RT
- .LP
- \(em
- referring to the ISDN capabilities;
- .LP
- \(em
- having a global significance in the lower layers.
- .PP
- The set of all GFs leads to the description of the total ISDN low layer
- capabilities.
- .PP
- \fINote\fR \ \(em\ This concept of global function may be extended to describe
- the higher layer capabilities of ISDN terminals (and network capabilities,
- where these exist). In this case the GF has a global significance inside the
- higher layers.
- .bp
- .RT
- .LP
- .rs
- .sp 13P
- .ad r
- \fBFigure 3/I.310, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- There are two kinds of GFs:
- .LP
- \(em
- the
- Basic Global Functions
- (BGF), are those global
- functions needed to support ISDN basic services. The BGFs are
- related to ISDN connection types, as indicated in
- Table\ 1/I.310;
- .LP
- \(em
- the
- Additional Global Functions
- (AGF), are related
- to the ISDN capability to support supplementary services.
- Details of the relationship between AGFs and the ISDN
- capability to support supplementary services are given in
- \(sc\ 4.1.2.
- .sp 1P
- .LP
- 3.2.2
- \fIElementary functions\fR \fI(EF)\fR
- .sp 9p
- .RT
- .PP
- The introduction of the GF concept allows a general description of low
- layer capabilities.
- .PP
- The following is a more detailed description: for each GF, a set of
- elementary functions is identified as the set of basic elements which are
- then \fIallocated\fR to different functional entities involved in the
- communication.
- .PP
- GF\ =\ (EF1,\ EF2,\ EF3,\ . | | \ EFn)
- .PP
- An EF within this Recommendation is the lowest level of
- functionality. It is allocated to a functional entity involved in supporting
- a telecommunication service. An EF is an intrinsically static description
- of the capability of performing an action on a resource when defined conditions
- are
- met.
- .PP
- For building up a GF, each associated EF must be present in one or
- more functional entities of the ISDN. (In this context the ISDN may include
- the terminals, the network or specialized service centres.) But in a specific
- functional entity the complete set of associated EFs need not be present
- (see for example Figure\ 4/I.310).
- .RT
- .LP
- .rs
- .sp 14P
- .ad r
- \fBFigure 4/I.310, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- 3.2.3
- \fIAllocation of EFs\fR
- .sp 9p
- .RT
- .PP
- This flexibility in construction of EFs allows a specialization of the
- functions to be allocated to particular functional entities. Because the
- Recommendations on the architecture of the ISDN (Recommendation\ I.324) will
- only specify a functional approach to standardization, the relationship
- between functional entities and specific equipment is, in general, a national
- matter. However an important first step in allocation of functions will
- be the
- distinction between terminal equipment and the network equipment
- involved.
- .PP
- Recommendation I.324 introduces the functional grouping CRF
- (connection related functions). The CRF can be local, national transit or
- international transit. EFs can be associated with each of these.
- .RT
- .sp 1P
- .LP
- 3.3
- \fIDynamic description model\fR
- .sp 9p
- .RT
- .PP
- The complete description of ISDN capabilities must include dynamic aspects
- involved in the process of a call.
- .PP
- This association of functional and protocol aspects leads to the use of
- the following dynamic description method:
- .RT
- .sp 1P
- .LP
- 3.3.1
- \fIInformation flow diagrams\fR
- .sp 9p
- .RT
- .PP
- The operation of basic and supplementary services are described and characterized,
- as seen from a network point of view, by using information flow diagrams
- which show the sequence of events occurring in the course of the
- call.
- .RT
- .sp 1P
- .LP
- 3.3.2
- \fIExecutive processes\fR
- .sp 9p
- .RT
- .PP
- An executive process (EP) corresponds to the particular use of
- one or more elementary functions within a particular functional entity which
- always yields specific results. Therefore an EP is characterized by input
- information it needs for execution and by output information or actions
- resulting from execution.
- .PP
- Executive processes involve (see Figure\ 5/I.310):
- .RT
- .LP
- a)
- sequences that link together events producing the activation
- of an EP, by means of signalling information passed between
- the function entities;
- .LP
- b)
- the information (or data) actually used:
- .LP
- \(em
- protocol information (signalling information sent or
- received by the component);
- .LP
- \(em
- component information (\*Qnetwork information\*U);
- .LP
- \(em
- static information (description of available resources,
- environment, services,\ etc.)
- .LP
- \(em
- dynamic information (elaborated and used during the
- call handling).
- .PP
- The dynamic description of each basic or supplementary service as required
- in stage\ 2 of the description method given in Recommendation\ I.130,
- based on the above elements, results in a chart showing functional entities
- involved (e.g.\ associated with originating and destination exchanges,
- specialized service centres when required), the signalling information flow
- passed between them, and the executive processes used inside them.
- .sp 2P
- .LP
- \fB4\fR \fBUse of\fR
- \fBgeneric description model\fR
- .sp 1P
- .RT
- .PP
- The analysis of telecommunication services and technological
- development leads to the identification of the range of required
- functions.
- .PP
- The analysis of all the basic and supplementary services provided by the
- ISDN will lead to the establishment of a set of elementary functions which
- can be allocated to different functional entities.
- .PP
- The design of a new basic or supplementary service should maximize the
- use of the set of existing EFs available to existing systems. This will
- minimize changes to the systems necessary for introducing these new services.
- The specifications for new equipment designed for providing particular
- services will have to comply with the set of EFs required for these
- services.
- .bp
- .RT
- .LP
- .rs
- .sp 19P
- .ad r
- \fBFigure 5/I.310, (N), p. 5\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 2P
- .LP
- 4.1
- \fIIdentification of\fR
- \fIISDN global functions\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 4.1.1
- \fIBasic global functions (BGF)\fR
- .sp 9p
- .RT
- .PP
- The basic global functions correspond to the ISDN capability to
- provide the various connection types that support telecommunication
- services.
- .PP
- The functions implemented to support telecommunication services can be
- classified into the following categories:
- .RT
- .LP
- \(em
- \fIConnection handling:\fR | functions which enable the
- establishment (set\(hyup), holding and release of connections
- (e.g.\ user\(hyto\(hynetwork signalling).
- .LP
- \(em
- \fIRouting:\fR | functions that determine a suitable connection
- for a particular service (call) request, i.e.\ suitable paths between the
- various equipments and inside the switching systems to establish end\(hyto\(hyend
- connections (e.g.\ called number analysis).
- .LP
- \(em
- \fIResources handling:\fR | functions that enable the control of the
- resources necesary for the use of connections (e.g.\ transmission equipment,
- switching resources, data storage equipment).
- .LP
- \(em
- \fISupervision:\fR | functions that check the resources used to
- support the connections, to detect and signal possible problems and to solve
- them if possible (e.g.\ transmission error detection and correction).
- .LP
- \(em
- \fIOperation and maintenance:\fR | functions providing the
- capability to control the correct working of the services/network as well
- for the subscribers as for the Administration.
- .LP
- \(em
- \fICharging:\fR | functions providing the capability to the
- Administration to charge the subscribers.
- .LP
- \(em
- \fIInterworking:\fR | functions providing the capability for both service
- and network interworking.
- .LP
- \(em
- \fILayer 2 and 3 data unit handling:\fR | functions providing
- handling of layers\ 2 and\ 3 data units during the information transfer
- phase for the case of packet mode connections.
- .PP
- According to this classification, a basic global function is
- defined as:
- .LP
- \(em
- referring to an ISDN connection type;
- .LP
- \(em
- belonging to one of the above categories.
- .PP
- Table 1/I.310 shows the total set of BGFs.
- .bp
- .ce
- \fBH.T. [T1.310]\fR
- .ce
- TABLE\ 1/I.310
- .ce
- \fBISDN basic global functions\fR
- .ps 9
- .vs 11
- .nr VS 11
- .nr PS 9
- .TS
- center box;
- lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
- {
- Connection
- type
- Category
- } CT 1 CT 2 . | | CT n
- _
- .T&
- lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
- Connection handling 1 BGF 1 2 BGF 1 n BGF 1
- _
- .T&
- lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
- Routing 1 BGF 2 2 BGF 2 n BGF 2
- _
- .T&
- lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
- Resources handling 1 BGF 3 2 BGF 3 n BGF 3
- _
- .T&
- lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
- Supervision 1 BGF 4 2 BGF 4 n BGF 4
- _
- .T&
- lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
- Operation and maintenance 1 BGF 5 2 BGF 5 n BGF 5
- _
- .T&
- lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
- Charging 1 BGF 6 2 BGF 6 n BGF 6
- _
- .T&
- lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
- Interworking 1 BGF 7 2 BGF 7 n BGF 7
- _
- .T&
- lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
- {
- Layer 2 and 3 data unit handling
- } 1 BGF 8 2 BGF 8 n BGF 8
- _
- .TE
- .nr PS 9
- .RT
- .ad r
- \fBTableau 1/I.310, [T1.310], p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .sp 3
- .sp 1P
- .LP
- 4.1.2
- \fIAdditional global functions (AGF)\fR
- .sp 9p
- .RT
- .PP
- The additional global functions corresponds to the ISDN capability to support
- supplementary services.
- .PP
- The classification of AGFs is based on the principle that the support of
- a supplementary service is considered as being realized by a number of
- functions distributed throughout the ISDN. The definition of AGFs needs
- further study.
- .RT
- .sp 1P
- .LP
- 4.2
- \fIIdentification of\fR
- \fIISDN elementary functions\fR
- .sp 9p
- .RT
- .PP
- Like GFs, there are two kinds of elementary functions: the basic
- EFs (i.e.\ components of BGFs, and possibly AGFs) and the additional EFs
- (i.e.\ components of AGFs). Therefore, identification of basic EFs requires a
- detailed analysis of connection types. Implementation and identification of
- additional EFs requires a detailed analysis of supplementary services
- implementation.
- .RT
- .LP
- \(em
- \fIBasic EFs:\fR | for each connection type, there are up to
- 8\ BGFs to implement (see Table\ 1/I.310). Therefore each BGF is composed of
- basic EFs related to this connection type. However some basic EFs may be
- common to several connection types (e.g.\ \*Qcalled number analysis\*U
- belonging to the BGF \*Qrouting\*U).
- .LP
- \(em
- \fIAdditional EFs:\fR | additional EFs form a common set of
- functional elements available to build up the various AGFs, and thus to
- implement supplementary services.
- .bp
- .PP
- This grouping of EFs into sets of BGFs and AGFs is illustrated in Figure\
- 6/I.310.
- .PP
- The list of EFs so far identified is contained in Annex\ A, together
- with a preliminary set of definitions.
- .RT
- .LP
- .rs
- .sp 28P
- .ad r
- \fBFigure 6/I.310, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- 4.3
- \fIIdentification of\fR
- \fIISDN executive processes\fR
- .sp 9p
- .RT
- .PP
- A possible use of the concept of an Executive Process (EP) is the definition
- of Functional Components (FC) as executive processes that can be invoked
- by the network to realize a telecommunication service.
- .PP
- According to this an FC is a specific example of how to use the EP
- concept.
- .PP
- A functional component is a set of elementary functions performed in an
- order that yields a specified result. An FC always has an invoking and
- a
- responding entity. The
- invoking entity
- is the entity which acts in
- response to an FC request from an invoking entity.
- .PP
- In defining an FC, the following guidelines should be
- considered:
- .RT
- .LP
- \(em
- FCs are used as building blocks and may be invoked in order to realize
- a telecommunication service. FCs will have signalling impact and
- should be structured in such a way that several telecommunication services
- can use them. In particular, the definition of an FC should as far as possible
- be independent of any connection type.
- .LP
- \(em
- A new FC should not be defined if its functionality can be
- provided by one or more existing FCs. As an objective, an FC will not invoke
- another FC.
- .PP
- The relationship between an FC and EFs is shown in
- Figure\ 7/I.310.
- .bp
- .LP
- .rs
- .sp 14P
- .ad r
- \fBFigure 7/I.310, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- Once invoked, the responding entity will not be affected by
- unsolicited inputs from the invoking entity. However, the request for
- execution of an FC may be cancelled by the invoking entity if the request
- was received.
- .PP
- It should also be noted that the functionality of an FC could be
- invoked by a user equipment, i.e.\ the invoking entity of an FC could be
- allocated to user equipment. When an FC affects the user\(hynetwork interface a
- service description is needed. Figure\ 8/I.310 illustrates FCs affecting
- different interfaces, FC1 affecting the user\(hynetwork interface, FC2
- affecting an internal network interface. It also illustrates that the invoking
- and
- responding entities of different FCs may appear in the same functional
- entity.
- .RT
- .LP
- .rs
- .sp 17P
- .ad r
- \fBFigure 8/I.310, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- FCs are building blocks, which by themselves are not sufficient to provide
- a service. There is a need for some logic reflecting how FCs are
- coordinated in order to support a given service: this logic is termed
- service control
- . Service control is an example of the application
- process concept which can be found in other Recommendations.
- .PP
- Annex B gives descriptions of FCs so far identified for the
- ISDN.
- .bp
- .RT
- .sp 2P
- .LP
- \fB5\fR \fBFunctional realization of\fR
- \fBbasic service requests\fR
- .sp 1P
- .RT
- .PP
- From the functional point of view, the process involved in
- satisfying a basic service request in the ISDN can be described as
- follows:
- .RT
- .LP
- a)
- A basic service request contains a set of attribute values.
- The appropriate connection type(s) to support the service
- must be identified.
- .LP
- Service request examination:
- .LP
- \(em
- input: service request containing a set of attribute
- values;
- .LP
- \(em
- process: examine service request and determine
- appropriate connection type(s);
- .LP
- \(em
- output: connection type(s).
- .LP
- b)
- Once selected, the connection type (which has end\(hyto\(hyend
- significance) can be further broken down into one or more
- smaller functional components called \*Qconnection elements\*U
- (see Recommendation\ I.324).
- .LP
- Connection element selection:
- .LP
- \(em
- input: connection type;
- .LP
- \(em
- process: determine connection element(s) to form the
- connection type;
- .LP
- \(em
- output: connection element(s).
- .LP
- c)
- Each connection element would require a set of functions in
- order to be established.
- .LP
- Function set determination:
- .LP
- \(em
- input: connection element;
- .LP
- \(em
- process: select appropriate functions to establish
- connection element;
- .LP
- \(em
- output: set of functions.
- .ce 1000
- ANNEX A
- .ce 0
- .ce 1000
- (to Recommendation I.310)
- .sp 9p
- .RT
- .ce 0
- .LP
- A.1
- \fIList of identified basic elementary functions and additional\fR \fIelementary
- functions (EFs) for the ISDN\fR
- .sp 1P
- .RT
- .sp 2P
- .LP
- A.1.1
- \fIBASIC EFs related to connection types\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- \fIConnection handling\fR
- .sp 9p
- .RT
- .LP
- BEF100
- Characteristics of service requested
- examination
- .LP
- BEF101
- Connection elements type determination
- .LP
- BEF102
- User\(hynetwork access resources reservation
- (channels)
- .LP
- BEF103
- Transit resources reservation
- .LP
- BEF104
- Communication references handling
- .LP
- BEF
- 104\ E:
- Establish call reference
- .LP
- BEF
- 104\ C:
- Clear call reference
- .LP
- BEF105
- Establishment control
- .LP
- BEF
- 105\ R:
- Establish connection\(hyreturn path only
- .LP
- BEF
- 105\ F:
- Establish connection\(hyforward path
- .LP
- BEF
- 150\ B:
- Establish connection\(hyboth directions
- .LP
- BEF106
- Release control
- .LP
- BEF107
- Service related authorizations examination
- .LP
- BEF108
- User\(hynetwork signalling handling (layer\ 3)
- .LP
- BEF109
- Inter\(hyexchange signalling handling (user part)
- .LP
- BEF110
- Supplementary services compatibility checking
- .LP
- BEF111
- Building up of and maintaining dynamic information
- relating to the call/connection
- .LP
- BEF112
- Signalling interworking
- .LP
- BEF113
- Priority
- .LP
- BEF114
- Queue handling
- .bp
- .sp 1P
- .LP
- \fIRouting\fR
- .sp 9p
- .RT
- .LP
- BEF200
- ISDN number identification
- .LP
- BEF201
- Called number analysis (address analysis)
- .LP
- BEF202
- Routing information examination (if provided)
- .LP
- BEF203
- Predetermined specific routing
- .LP
- BEF204
- Connection path selection
- .LP
- BEF205
- Rerouting
- .sp 1P
- .LP
- \fIResources handling\fR
- .sp 9p
- .RT
- .LP
- BEF300
- Hold and release of user\(hynetwork access resources
- (channels)
- .LP
- BEF
- 300\ H:
- Hold user\(hynetwork access resources
- .LP
- BEF
- 300\ R:
- Release user\(hynetwork access resource
- .LP
- BEF301
- Hold and release of transit resources (circuits)
- .LP
- BEF
- 301\ H:
- Hold transit resources
- .LP
- BEF
- 301\ R:
- Release transit resources
- .LP
- BEF302
- Insertion and suppression of specific equipment
- .LP
- BEF303
- Tones, announcements and display information
- .LP
- BEF304
- User\(hynetwork signalling handling (layer 1\(hy2)
- .LP
- BEF305
- Inter\(hyexchange signalling handling (message
- transfer)
- .LP
- BEF306
- Path search inside switching unit
- .LP
- BEF307
- Synchronization handling
- .LP
- BEF308
- Timing handling
- .LP
- BEF309
- Line service marking
- .LP
- BEF310
- Real time clock
- .sp 1P
- .LP
- \fISupervision\fR
- .sp 9p
- .RT
- .LP
- BEF400
- User\(hynetwork access resources monitoring
- .LP
- BEF401
- Transit resources monitoring
- .LP
- BEF402
- Continuity checking
- .LP
- BEF403
- Detection of congestion
- .LP
- BEF404
- Semi\(hypermanent connection checking
- .sp 1P
- .LP
- \fIOperation and maintenance\fR
- .sp 9p
- .RT
- .LP
- BEF500
- Management of subscriber data
- .LP
- BEF501
- Fault report
- .sp 1P
- .LP
- \fICharging\fR
- .sp 9p
- .RT
- .LP
- BEF600
- Charging management
- .LP
- BEF
- 600\ I:
- Initiate charging
- .LP
- BEF
- 600\ C:
- Cease charging
- .LP
- BEF601
- Charging registering
- .LP
- BEF602
- Charging recording
- .LP
- BEF603
- Billing
- .LP
- BEF604
- Accounting
- .LP
- BEF605
- Charging information
- .sp 1P
- .LP
- \fIInterworking\fR
- .sp 9p
- .RT
- .LP
- BEF700
- Rate adaption
- .LP
- BEF701
- Protocol conversion
- .LP
- BEF702
- Handling of signalling for interworking
- .LP
- BEF703
- Numbering interworking
- .LP
- BEF704
- Special routing algorithms
- .LP
- BEF705
- Negotiation
- .LP
- BEF706
- Notification
- .LP
- BEF707
- Charging for interworking
- .LP
- BEF708
- Mapping of lower layer comparability
- .bp
- .sp 2P
- .LP
- A.1.2
- \fIAEFs relating to supplementary services\fR
- .sp 1P
- .RT
- .LP
- AEF00
- Insertion and suppression of additional resources
- (tones\ etc.)
- .LP
- AEF01
- Line hunting
- .LP
- AEF02
- Direct dialling\(hyin
- .LP
- AEF03
- Address determination
- .LP
- AEF04
- Subscriber's dedicated storage
- .LP
- AEF05
- Bridge
- .LP
- AEF06
- User\(hynetwork access resource hold
- .LP
- AEF07
- Hold of communication
- .LP
- AEF08
- Additional subscriber signalling
- .LP
- AEF09
- Additional inter\(hyexchange signalling
- .LP
- AEF10
- Multi\(hycall handling
- .LP
- AEF11
- Internal call initialization
- .LP
- AEF12
- Access/route restriction
- .LP
- AEF13
- Subscriber call data registration
- .LP
- AEF14
- Data display option
- .LP
- A.2\ \ \fIShort description of elementary functions\fR
- .sp 1P
- .RT
- .sp 2P
- .LP
- A.2.1\ \ \fIBasic EFs related to connection types\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- A.2.1.1\ \ \fIConnection handling\fR
- .sp 9p
- .RT
- .sp 1P
- .LP
- 100
- \fICharacteristics of service requested examination\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to determine the required service characteristics
- (certain attributes of the bearer service and optional
- supplementary services) of a call by means of examination of information
- set by calling terminal.
- .RT
- .sp 1P
- .LP
- 101
- \fIConnection elements type determination\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to determine connection types and connection
- elements necessary to provide the requested service.
- .RT
- .sp 1P
- .LP
- 102
- \fIUser access resources reservation\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to determine the type of
- user\(hynetwork access (basic, primary), the state of the resources (channels
- availability) and to reserve the channel(s) needed for establishing the
- access connection element.
- .RT
- .sp 1P
- .LP
- 103
- \fITransit resources reservation\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to reserve the transit connection element,
- based on the state of resources.
- .RT
- .sp 1P
- .LP
- 104
- \fICommunication references handling\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to assign a local reference (at the access
- interface) to the call and an internal reference (at the internal
- interface) to the connection, and to clear these references when the
- call/connection is cleared/released.
- .RT
- .LP
- 104\ E
- Establish call reference.
- (For further study.)
- .LP
- 104\ C
- Clear call reference.
- (For further study.)
- .sp 1P
- .LP
- 105
- \fIEstablishment control\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to set up a connection through the functional
- entity.
- .RT
- .LP
- 105\ R
- Establish connection\(hyreturn path only.
- (For further study.)
- .LP
- 105\ F
- Establish connection\(hyforward path.
- (For further study.)
- .LP
- 105\ B
- Establish connection\(hyboth direction.
- (For further study.)
- .bp
- .sp 1P
- .LP
- 106
- \fIRelease control\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to release a connection through the functional
- entity.
- .RT
- .sp 1P
- .LP
- 107
- \fIService related authorization examination\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to determine the authorization
- (calling or called user) relating to basic and supplementary services that
- have been subscribed to.
- .RT
- .sp 1P
- .LP
- 108
- \fIUser\(hynetwork signalling handling (layer 3)\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to support the layer\ 3 protocol of the
- user\(hynetwork signalling system.
- .PP
- \fINote\fR \ \(em\ For layers 1 and 2, see \(sc\ A.2.1.3, Resources
- handling.
- .RT
- .sp 1P
- .LP
- 109
- \fIInter\(hyexchange signalling handling (user part)\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to support the user part of the
- inter\(hyexchange signalling system.
- .RT
- .sp 1P
- .LP
- 110
- \fISupplementary services compatibility checking\fR
- .sp 9p
- .RT
- .PP
- Function of the network to check the compatibility of requested
- supplementary services, e.g.:
- .RT
- .LP
- \(em
- with requested bearer service to teleservice;
- .LP
- \(em
- with other requested supplementary services;
- .LP
- and to verify coherence between parameters that may be associated.
- .sp 1P
- .LP
- 111
- \fIBuilding\(hyup of and maintaining dynamic information related to the\fR
- \fIcall/connection\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to compile information related to the call/connection,\
- e.g.:
- .RT
- .LP
- \(em
- resources needed (connection type, connection elements,
- channels, circuits);
- .LP
- \(em
- details of call in progress;
- .LP
- \(em
- supplementary services effected and associated
- parameters.
- .sp 1P
- .LP
- 112
- \fISignalling interworking\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to support interworking functions between
- signalling systems.
- .RT
- .sp 1P
- .LP
- 113
- \fIPriority\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to handle specific calls
- with priority (e.g.\ in the case of overload or degraded mode of
- operation).
- .RT
- .sp 1P
- .LP
- 114
- \fIQueue handling\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to store requests in a
- queue, in order to handle this information later in a predefined
- order.
- .RT
- .sp 2P
- .LP
- A.2.1.2\ \ \fIRouting\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 200
- \fIISDN number identification\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to identify the ISDN number of the user\(hynetwork
- interface. This information is limited to that included within the ISDN
- numbering plan.
- .RT
- .sp 1P
- .LP
- 201
- \fICalled number analysis\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to analyse called ISDN number sent by the
- calling terminal in the call set\(hyup phase.
- .bp
- .RT
- .sp 1P
- .LP
- 202
- \fIRouting information examination\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to analyse routing information that may
- be sent by the calling terminal and that has an effect on path
- selection.
- .RT
- .sp 1P
- .LP
- 203
- \fIPredetermined specific routing\fR
- .sp 9p
- .RT
- .PP
- Function of an exchange to select a specific routing according to the information
- received from the calling terminal (for example routing towards operators,
- access points, an interworking unit, an operational or maintenance unit,\
- etc.).
- .RT
- .sp 1P
- .LP
- 204
- \fIConnection path selection\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to select the transit outgoing part relating
- to connection types to be used, and the overall path through the
- network.
- .RT
- .sp 1P
- .LP
- 205
- \fIRerouting\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to select a new connection path
- through the network depending on changed conditions during call set\(hyup or
- information transfer phases.
- .RT
- .sp 2P
- .LP
- A.2.1.3\ \ \fIResources handling\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 300
- \fIHold and release of user\(hynetwork access resources (channels)\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to hold the access channel(s)
- reserved to support the communication, and to release it at the end of this
- communication.
- .RT
- .LP
- 300\ H
- Hold user\(hynetwork access resource.
- (For further study.)
- .LP
- 300\ R
- Release user\(hynetwork access resource.
- (For further study.)
- .sp 1P
- .LP
- 301
- \fIHold and release of transit resources (circuits)\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to hold the circuit(s) reserved to support
- the communication at the transit connection element and to release it at
- the end of this communication.
- .RT
- .LP
- 301\ H
- Hold transit resources.
- (For further study.)
- .LP
- 301\ R
- Release transit resources.
- (For further study.)
- .sp 1P
- .LP
- 302
- \fIInsertion and suppresion of specific equipment\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to insert or remove specific
- equipments particularly to satisfy the service request invoked by the user.
- Examples of such equipment include:
- .RT
- .LP
- \(em
- echo suppressers;
- .LP
- \(em
- A\(hy\(*m law conversion units (change of A/D conversion);
- .LP
- \(em
- interworking unit;
- .LP
- \(em
- storage unit.
- .sp 1P
- .LP
- 303
- \fITones, announcements and display information\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to provide call progress
- information in one or more of the following ways:
- .RT
- .LP
- \(em
- a tone is an audible (call progress) indication comprising
- one or more discrete frequencies but excluding speech;
- .LP
- \(em
- a recorded announcement is an audible indication in the form of speech
- or music;
- .LP
- \(em
- display information is (call progress) information set to the user which
- is displayed visually.
- .PP
- Definitions of the other topics are not yet available.
- .bp
- .sp 1P
- .LP
- 304
- \fIUser\(hynetwork signalling handling (layers 1\(hy2)\fR
- .sp 9p
- .RT
- .PP
- Functions of a functional entity to support layers 1 and 2 of the user\(hynetwork
- signalling system.
- .RT
- .sp 1P
- .LP
- 305
- \fIInter\(hyexchange signalling handling (message transfer)\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to support the messages transfer
- part of the inter\(hyexchange signalling systems.
- .RT
- .sp 1P
- .LP
- 306
- \fIPath search inside switching unit\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to select an internal connection
- inside the switching unit.
- .RT
- .sp 1P
- .LP
- 307
- \fISynchronization handling\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to provide synchronization between different
- functional entities; and
- .PP
- Function of a functional entity to provide its own internal
- synchronization functional entity.
- .RT
- .sp 1P
- .LP
- 308
- \fITiming handling\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to provide timing between time
- instances involved in calls.
- .RT
- .sp 1P
- .LP
- 309
- \fILine service marking\fR
- .sp 9p
- .RT
- .PP
- Functions of a functional entity to store for each customer the
- data on the parameters of the bearer and teleservices that are subscribed
- to. The store also contains the data on the parameters of the basic bearer
- and
- teleservices that are subscribed to by the customer. In addition, it contains
- the binary information (i.e.\ subscribed to or not) for a range of supplementary
- services which the subscriber can use. In general this data does \fInot\fR
- contain information on the type of subscriber terminal, but it may contain
- information on the type of access (basic, primary rate,\ etc.), the type
- of NT2
- (simple, intelligent,\ etc.) and the attributes of the services
- subscribed\ to.
- .RT
- .sp 1P
- .LP
- 310
- \fIReal time clock\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to provide real time
- information.
- .RT
- .sp 2P
- .LP
- A.2.1.4\ \ \fISupervision\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 400
- \fIUser\(hynetwork access resources monitoring\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to check the correct operation of subscriber
- access resources.
- .RT
- .sp 1P
- .LP
- 401
- \fITransit resources monitoring\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to check the correct operation of the transit
- resources.
- .RT
- .sp 1P
- .LP
- 402
- \fIContinuity checking\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to control the checking operations relating
- to the continuity of a connection.
- .RT
- .sp 1P
- .LP
- 403
- \fIDetection of congestion\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to detect congestion during the
- selection of a connection path.
- .bp
- .RT
- .sp 1P
- .LP
- 404
- \fISemi\(hypermanent connection checking\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to check the availability of
- a given semi\(hypermanent connection (e.g.\ passive continuity
- checking).
- .RT
- .sp 2P
- .LP
- A.2.1.5\ \ \fIOperation and maintenance\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 500
- \fIManagement of subscriber data\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to manage subscriber data related to services.
- Examples include:
- .RT
- .LP
- \(em
- in/out of service
- .LP
- \(em
- number translation
- .LP
- \(em
- changing of subscriber data.
- .sp 1P
- .LP
- 501
- \fIFault report\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to register the cause if an attempt to
- set up a call fails.
- .RT
- .sp 2P
- .LP
- A.2.1.6\ \ \fICharging\fR | (the groupings below require further study)
- .sp 1P
- .RT
- .PP
- Function of the network to determine, collect and store the
- charging information. The following features are involved in this
- process:
- .RT
- .sp 1P
- .LP
- 600
- \fICharging management\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to determine by means of certain
- parameters the charging mode (free of charge, ordinary, peak, reduced
- rate charge,\ etc.). These parameters include service type, class of customer,
- time information, distance,\ etc.
- .RT
- .LP
- 600\ I
- Initiate charging.
- (For further study.)
- .LP
- 600\ C
- Cease charging.
- (For further study.)
- .sp 1P
- .LP
- 601
- \fICharging registering\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to register the details of the call (both
- short\(hy and long\(hyterm storage).
- .RT
- .sp 1P
- .LP
- 602
- \fICharging recording\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to format the charging details in a standardized
- way.
- .RT
- .sp 1P
- .LP
- 603
- \fIBilling\fR
- .sp 9p
- .RT
- .PP
- Function of functional entity to calculate the variable charges to the
- customer which depend on the use of a service and on the fixed costs of
- the subscription. Both of these are accumulated over a fixed period of
- time. This billing is associated with the subscriber and not with a user\(hynetwork
- interface, a terminal,\ etc.
- .RT
- .sp 1P
- .LP
- 604
- \fIAccounting\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to analyse, store and forward
- information relating to the use of inter\(hynetwork resources between the
- different Administrations involved in a call.
- .RT
- .sp 1P
- .LP
- 605
- \fICharging information\fR
- .sp 9p
- .RT
- .PP
- Function of the network to indicate the user the amount of the
- charge involved in the (current) use of the service.
- .bp
- .RT
- .sp 2P
- .LP
- A.2.1.7\ \ \fIInterworking\fR
- .sp 1P
- .RT
- .PP
- Functions that permit the establishment of end\(hyto\(hyend connections
- when an ISDN and a dedicated network are involved. This requires the provision
- of the basic elementary features (BEFs) which are described below and others
- that have been defined already (service request examination, signalling
- interworking, called number analysis, routing information examination,
- insertion and suppresion of interworking units,\ etc.).
- .RT
- .sp 1P
- .LP
- 700
- \fIRate adaption\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to adapt, according to a
- certain method, the user/dedicated network bit rates to the ISDN bit
- rates.
- .RT
- .sp 1P
- .LP
- 701
- \fIProtocol conversion\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to support mapping functions
- between interfaces.
- .RT
- .sp 1P
- .LP
- 702
- \fIHandling of signalling for interworking\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to handle signalling information
- for interworking (interpretation, termination, generation).
- .RT
- .sp 1P
- .LP
- 703
- \fINumbering interworking\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to support interworking functions between
- numbering plans.
- .RT
- .sp 1P
- .LP
- 704
- \fISpecial routing algorithms\fR | (For further study)
- .sp 9p
- .RT
- .sp 1P
- .LP
- 705
- \fINegotiation\fR | (For further study)
- .sp 9p
- .RT
- .sp 1P
- .LP
- 706
- \fINotification\fR | (For further study)
- .sp 9p
- .RT
- .sp 1P
- .LP
- 707
- \fICharging for interworking\fR | (For further study)
- .sp 9p
- .RT
- .sp 1P
- .LP
- 708
- \fIMapping of lower layer comparability (LLC) lists\fR | (For further
- study)
- .sp 9p
- .RT
- .sp 2P
- .LP
- A.2.2\ \ \fIAdditional EFs relating to supplementary services\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- AEF00\ \ \fIInsertion and suppression of additional resources (tone,\ etc.)\fR
- .sp 9p
- .RT
- .PP
- \fINote\fR \ \(em\ A definition has already been proposed for a basic EF.
- It needs to be considered if this feature should also be regarded as an
- additional feature. With respect to supplementary services a proposed description
- is:
- .PP
- Function of an exchange to manage (reserve, insert, release)
- additional resources related to the handling of supplementary
- services.
- .RT
- .sp 1P
- .LP
- AEF01\ \ \fILine hunting\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to select, on receipt of a certain terminal
- address, one free line in a multi\(hyline group corresponding to that
- number.
- .RT
- .sp 1P
- .LP
- AEF02\ \ \fIDirection dialling\(hyin\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to transfer address and other
- appropriate call handling information to a PABX for the purpose of setting
- up a call to its extensions without assistance of the PABX operator.
- .RT
- .sp 1P
- .LP
- AEF03\ \ \fIAddress determination\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to determine the destination
- number(s) called by means of short\(hylong number conversion or of association
- between one code and one list of numbers.
- .bp
- .RT
- .sp 1P
- .LP
- AEF04\ \ \fISubscriber's dedicated storage\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to store details in addition to the LSM
- (line service marking) for each customer and which contains the
- registration data for supplementary services that have been subscribed to
- (i.e.\ listed in the LSM as binary\ 1). For example, it would contain a
- list of abbreviated numbers.
- .RT
- .sp 1P
- .LP
- AEF05\ \ \fIBridge\fR
- .sp 9p
- .RT
- .PP
- Functions of a functional entity to allow more than two individual participants
- on the same call.
- .RT
- .sp 1P
- .LP
- AEF06\ \ \fIUser\(hynetwork access resource hold\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to hold the user\(hynetwork access
- resources (channel) involved in a communication in a waiting condition
- and, at the same time, to release the network connection. The call reference
- information is maintained.
- .RT
- .sp 1P
- .LP
- AEF07\ \ \fIHold of communication\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to initiate the function to hold
- one, or more, of the other parties engaged in an established call in a
- waiting condition without the disestablishment of the call, and at the
- same time to
- release the initiating user\(hynetwork access resource.
- .RT
- .sp 1P
- .LP
- AEF08\ \ \fIAdditional subcriber signalling\fR
- .sp 9p
- .RT
- .PP
- Functions of an exchange to send or receive specific signalling
- information to or from the user, related to the handling of supplementary
- services. (Additional signalling to the subscriber signalling for basic
- calls.)
- .RT
- .sp 1P
- .LP
- AEF09\ \ \fIAdditional inter\(hyexchange signalling\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to send or receive specific
- signalling information to or from another component, related to the handling
- of supplementary services. (Additional signalling to the inter\(hyexchange
- signalling for basic calls.)
- .RT
- .sp 1P
- .LP
- AEF10\ \ \fIMulti\(hycall handling\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to set up and manage several
- connections by means of a single procedure. (In response to only one call
- request.)
- .RT
- .sp 1P
- .LP
- AEF11\ \ \fIInternal call initialization\fR
- .sp 9p
- .RT
- .PP
- Functions of a functional entity to initiate the setting\(hyup of a
- connection without receiving a call request from the user [e.g.\ used for
- Completion of Call to Busy Subscribers (CCBS) supplementary service and
- alarm call services].
- .RT
- .sp 1P
- .LP
- AEF12\ \ \fIAccess/route restriction\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to reject incoming or outgoing
- calls, either:
- .RT
- .LP
- \(em
- totally for all services, or
- .LP
- \(em
- for one type of service (e.g.\ telephony).
- .sp 1P
- .LP
- AEF13\ \ \fISubscriber call data registration\fR
- .sp 9p
- .RT
- .PP
- Function of a functional entity to register and display or print
- subscriber call data. Subscriber call data is information related to specific
- calls. This data is collected by the same functional entity as that which
- contains the EF \*Qsubscriber call data registration\*U.
- .RT
- .sp 1P
- .LP
- AEF14\ \ \fIData display option\fR
- .sp 9p
- .RT
- .PP
- Functions of a terminal to display information to the
- user.
- .bp
- .RT
- .ce 1000
- ANNEX\ B
- .ce 0
- .ce 1000
- (to Recommendation I.310)
- .sp 9p
- .RT
- .ce 0
- .ce 1000
- \fBDescriptions of identified \fR \fBfunctional components (FCs)\fR \fBfor
- the ISDN\fR
- .sp 1P
- .RT
- .ce 0
- .LP
- B.1
- \fIHold invocation\fR
- .sp 1P
- .RT
- .PP
- This FC allows to invoke the disconnection of an established
- communication channel between the initiating and responding entities and its
- resevation for subsequent reuse for another (or the previous) communication.
- This implies the interruption of the communication for an existing connection.
- .PP
- The initiating entity provides the information required to identify
- the connection to be interrupted.
- .PP
- The successful application of this FC results in:
- .RT
- .LP
- \(em
- the disconnection of the communication channel between the
- initiating and the responding entities;
- .LP
- \(em
- the reservation of the disconnected communication channel
- for the initiating entity (for originating or terminating
- connections);
- .LP
- \(em
- an indication of successful completion from the responding
- entity.
- .PP
- The unsuccessful application of this FC results in a response
- containing the failure details.
- .PP
- \fINote\fR \ \(em\ The exact definition of communication channel is for
- further study.
- .RT
- .sp 1P
- .LP
- B.2
- \fIRetrieve\fR
- .sp 9p
- .RT
- .PP
- This FC allows the initiating entity to request the reconnection of a communication
- channel between the initiating and responding entities in order to re\(hyestablish
- a previously held connection.
- .PP
- The initiating entity provides the information required to identify
- the connection to be re\(hyestablished over the reserved communication
- channel.
- .PP
- The successful completion of this FC results in:
- .RT
- .LP
- \(em
- the re\(hyestablishment of the connection. The communication
- channel will be the reserved channel whenever possible. If exceptionally an
- alternate channel had to be allocated, the responding entity will indicate
- its identity;
- .LP
- \(em
- an indication of succesful completion from the responding
- entity.
- .PP
- The unsuccessful application of the FC results in a response
- containing the failure details.
- .PP
- The possible re\(hyestablishment of a connection over another
- communication channel than the reserved one is for further study.
- .RT
- .sp 1P
- .LP
- B.3
- \fIJoin\fR
- .sp 9p
- .RT
- .PP
- This FC allows to invoke the addition of a connection in order
- to form, or to add to, a multiparty connection of the same connection
- type.
- .PP
- The initiating entity provides all information required to identify
- the connection to be joined to the multi\(hyparty connection. The responding
- entity executes the functions to join the connection and provides the
- initiating entity with the information of the result of the execution.
- .PP
- Upon successful completion, all connections involved are connected
- together. A successful indication is returned to the initiating
- entity.
- .PP
- Upon unsuccessful completion, the status of last connection remains
- unchanged and an unsuccessful indication is returned to the initiating party
- with failure cause(s).
- .RT
- .sp 1P
- .LP
- B.4
- \fISplit\fR
- .sp 9p
- .RT
- .PP
- This FC allows the initiating entity to separate a connection from a multiparty
- connection.
- .PP
- The initiating entity provides the identities of the multiparty
- connection and the connection to be separated. The responding entity executes
- the functions to separate the designated connection from the multiparty
- connection.
- .bp
- .PP
- Upon successful completion the designated connection is
- separated from the multiparty connection. The separated connection is put on
- hold; the remainder of the multiparty connection remains unchanged. A
- successful indication is returned to the initiating entity.
- .PP
- Upon unsuccessful completion, the status of the multiparty connection remains
- unchanged and an unsuccessful indication is returned to the initiating
- party with failure cause(s).
- .RT
- .sp 1P
- .LP
- B.5
- \fITransfer\fR
- .sp 9p
- .RT
- .PP
- This FC allows the initiating entity to reassign the ownership of a call
- to an elected subscriber.
- .PP
- The initiating entity provides the identity of the connection to be
- transferred and the identity of the elected subscriber.
- .PP
- Successful completion of this FC results in:
- .RT
- .LP
- \(em
- the elected subscriber assumes the subsequent charges;
- .LP
- \(em
- the initiating entity receives a successful confirmation from the responding
- entity;
- .LP
- \(em
- the initiating entity is disconnected from the transferred
- connection.
- .PP
- Upon unsuccessful completion, the status of the connection
- remains unchanged and an unsuccessful indication is returned to the initiating
- party with failure cause(s).
- .PP
- \fINote\fR \ \(em\ The concept of ownership requires further investigation in
- relation to control and charging aspects.
- .RT
- .sp 1P
- .LP
- B.6
- \fINotify\fR
- .sp 9p
- .RT
- .PP
- This FC provides the capability for one entity to inform another
- entity of some action or condition without requiring a response from the
- receiving entity.
- .PP
- \fINote\fR \ \(em\ A more precise definition of this FC is required.
- .RT
- .sp 1P
- .LP
- B.7
- \fIEnquire\fR
- .sp 9p
- .RT
- .PP
- This FC provides the capability for the initiating entity to
- request information from another entity, without changing that information.
- .PP
- The initiating entity provides to the responding entity what
- information is requested and other information the responding entity needs
- to respond successfully. For example, in requesting information from the
- responding entity about busy/idle status of an interface, the initiating
- entity provides information uniquely identifying that interface.
- .PP
- Upon successful completion, the responding entity returns to the
- initiating entity the requested information.
- .PP
- Upon unsuccessful completion, the responding entity returns an
- unsuccessful indication including failure cause(s).
- .RT
- .sp 1P
- .LP
- B.8
- \fIAdjourn\fR
- .sp 9p
- .RT
- .PP
- This FC provides the capability for the initiating and responding entities
- to retain knowledge of a call ( or call attempt) sufficient for
- subsequent re\(hyestablishment.
- .PP
- The initiating entity provides to the responding entity the identity of
- the call to be adjourned.
- .PP
- Upon successful completion, all channels previously allocated for the call
- (or call attempt) are released and the knowledge of the call is
- retained.
- .PP
- Upon unsuccessful completion, the status of the call remains unchanged
- and an unsuccessful completion indication with failure cause(s) is returned
- to the initiating entity.
- .RT
- .sp 1P
- .LP
- B.9
- \fIRestart\fR
- .sp 9p
- .RT
- .PP
- This FC provides the capability for the initiating entity to
- allocate resources to restore an adjourned call.
- .PP
- The initiating entity provides the identity of the adjourned call to be
- restored.
- .PP
- Upon successful completion, the necessary resources to re\(hyestablish
- the call are restored and the call set\(hyup process resumes.
- .PP
- Upon unsuccessful completion, the adjourned call is released and a
- failure indication returned to the initiating entity including failure
- cause(s).
- .bp
- .RT
- .sp 1P
- .LP
- B.10
- \fIMonitor\fR
- .sp 9p
- .RT
- .PP
- This FC allows the initiating entity to watch for an event
- (e.g.\ transition to idle, transition to busy) on a resource. The resource
- being monitored may be a network resource or a user resource.
- .PP
- The initiating entity provides the identity of the resource to be
- monitored, the event to be reported, and optionally the period of the monitor
- function. If the event to be monitored is the availability of a resource,
- the initiating entity may also request the resource be reserved when it
- becomes
- available. The responding entity will indicate acceptance or rejection
- of the monitor request immediately and subsequently check the states of
- the resource during the period specified.
- .PP
- Upon successful completion, the responding entity will notify the
- intiating entity if the period expired before the monitored event
- occured.
- .PP
- Upon unsuccessful completion, an unsuccessful indication is returned to
- the initiating entity with failure cause(s).
- .RT
- .sp 1P
- .LP
- B.11
- \fIReroute\fR
- .sp 9p
- .RT
- .PP
- The FC allows the initiating entity to redirect an incoming call to an
- alternate address before the call is established.
- .PP
- The initiating entity provides the identity of the incoming call and the
- aternate address to where the incoming call is to be redirected.
- .PP
- Upon successful completion, the incoming call is connected to the
- alternate address.
- .PP
- Upon unsuccessful completion, the responding entity provides to the
- initiating entity the cause of failure and the call processing of the incoming
- call is resumed.
- .RT
- .LP
- .rs
- .sp 28P
- .ad r
- BLANC
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .ce 1000
- \v'3P'
- SECTION\ 2
- .ce 0
- .sp 1P
- .ce 1000
- \fBREFERENCE\ MODELS\fR
- .ce 0
- .sp 1P
- .sp 2P
- .LP
- \fBRecommendation\ I.320\fR
- .RT
- .sp 2P
- .sp 1P
- .ce 1000
- \fBISDN\ PROTOCOL\ REFERENCE\ MODEL\fR
- .EF '% Fascicle\ III.8\ \(em\ Rec.\ I.320''
- .OF '''Fascicle\ III.8\ \(em\ Rec.\ I.320 %'
- .ce 0
- .sp 1P
- .ce 1000
- \fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR
- .sp 9p
- .RT
- .ce 0
- .sp 1P
- .LP
- \fB1\fR \fBIntroduction\fR
- .sp 1P
- .RT
- .PP
- The objective of the ISDN Protocol Reference Model (ISDN PRM) is to model
- the interconnection and exchange of information\ \(em\ including user
- information and control information\ \(em\ to, through or inside an ISDN.
- .PP
- Communicating entities may be:
- .RT
- .LP
- \(em
- ISDN users;
- .LP
- \(em
- an ISDN user and a functional entity within an ISDN, e.g.
- network control facilities;
- .LP
- \(em
- an ISDN user and a functional entity inside or outside an
- ISDN, e.g.\ an information storage/processing/messaging facility;
- .LP
- \(em
- various functional entities in an ISDN, e.g. a network
- management facility and a switching facility;
- .LP
- \(em
- an ISDN functional entity and an entity located in or
- attached to a non\(hyISDN network.
- .PP
- The purpose of communications between these functional entities is to support
- the telecommunication services introduced in Recommendations\ I.211 and
- I.212, by providing ISDN capabilities as defined in Recommendation\ I.310.
- Examples of these capabilities are:
- .LP
- \(em
- circuit\(hyswitched connection under the control of common
- channel signalling;
- .LP
- \(em
- packet\(hyswitched communication over B\(hy, D\(hy and
- H\(hychannels;
- .LP
- \(em
- signalling between users and network\(hybased facilities (e.g. information
- retrieval systems such as Videotex, operations data bases such as directory);
- .LP
- \(em
- end\(hyto\(hyend signalling between users (e.g. to change mode of communication
- over an already established connection);
- .LP
- \(em
- combinations of the above as in multi\(hymedia communication,
- whereby several simultaneous modes of communication can take place under
- common signalling control.
- .PP
- With such diversity of ISDN capabilities (in terms of information flows
- and modes of communication), there is a need to
- model all these capabilities within a common framework (i.e. reference
- model). This would enable the critical protocol architectural issues to
- be readily
- identified and facilitate the development of ISDN protocols and associated
- features. It is not intended as a definition of any specific implementation
- of an ISDN or of any systems or equipment in, or connected to, an ISDN.
- .PP
- Examples of applications of this model are included in this
- Recommendation.
- .bp
- .RT
- .sp 2P
- .LP
- \fB2\fR \fBModelling concepts\fR
- .sp 1P
- .RT
- .sp 1P
- .LP
- 2.1
- \fIRelationship with the X.200\(hySeries\fR
- .sp 9p
- .RT
- .PP
- The ISDN Protocol Reference Model (ISDN PRM) and the Open Systems Interconnection
- Reference Model (OSI\ RM) for CCITT Applications, defined by
- Recommendation X.200, have both commonalities and differences.
- .PP
- Both the ISDN PRM and the OSI RM organize communications functions
- into layers and describe the relation of these layers with respect to each
- other. However, the scope of the ISDN PRM is different from the scope of
- the OSI RM.
- .PP
- The scope of the ISDN PRM is to model information flows across the
- range of telecommunication services defined in the I.200\(hySeries. These are
- bearer services, teleservices and supplementary services. This description
- necessarily incorporates ISDN\(hyspecific characteristics not encountered
- in other network types. Among these characteristics are multi\(hyservice
- types of
- communications which include voice, video, data and multi\(hymedia
- communications.
- .PP
- The scope of the OSI RM is not associated with any particular network type
- .FS
- Note that the term \*Qnetwork\*U in the ISDN corresponds to \*Qsub\(hynetwork\*U
- in the OSI terminology.
- .FE
- . In that sense it is less specific than the ISDN PRM. Further, the scope
- of the OSI PRM is tied to data communications and so, in this respect,
- its scope is more specific than the ISDN PRM. The OSI is used to model
- data communications between open systems in an ISDN environment.
- .PP
- The relative scopes of the two models are illustrated by
- Figure\ 1/I.320. The existence of a common intersection shows that these
- models coexist and overlap.
- .RT
- .LP
- .rs
- .sp 19P
- .ad r
- \fBFigure 1/I.320, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- However, in spite of these differences in scope, a number of
- concepts and the associated terminology which have been introduced in\fR
- Recommendations\ X.200 and\ X.210 are fully applicable to the ISDN PRM. They
- include the concept of layer, layer service (Recommendation\ X.200), and the
- notions of service primitive, peer entity and peer protocol
- (Recommendation\ X.210).
- .PP
- \fINote\fR \ \(em\ The relation between service primitives and functional
- components introduced in Recommendation I.310 requires further study.
- .PP
- The layer identification used in Recommendation\ X.200 is limited
- in this Recommendation to the use of layer numbers. Layer titles (e.g.
- network layer) as used in Recommendation\ X.200 are sometimes misleading
- in the ISDN
- context, and have not been used here.
- .bp
- .PP
- The following ISDN needs have to be specifically catered for in
- Recommendation\ I.320:
- .RT
- .LP
- \(em
- information flows for out\(hyof\(hyband call control processes,
- or more generally, information flows among multiple related
- protocols;
- .LP
- \(em
- information flows for selection of connection
- characteristics;
- .LP
- \(em
- information flows for re\(hynegotiation of connection
- characteristics of calls;
- .LP
- \(em
- information flows for suspension of connections;
- .LP
- \(em
- information flows for overlap sending ;
- .LP
- \(em
- information flows for multi\(hymedia calls;
- .LP
- \(em
- information flows for asymmetric connections;
- .LP
- \(em
- information flows for network management
- (e.g. change over and change back) and for maintenance
- functions (e.g\ test loops);
- .LP
- \(em
- information flows for power activation/deactivation;
- .LP
- \(em
- interworking;
- .LP
- \(em
- switching of information flows;
- .LP
- \(em
- new layer service definitions for non\(hydata services;
- .LP
- \(em
- application to other than end\(hysystems, e.g. signal transfer
- points (STPs) and interworking points;
- .LP
- \(em
- information flows for multi\(hypoint connections;
- .LP
- \(em
- information flows for applications such as:
- .LP
- i)
- voice (including A/\(*m law conversion),
- .LP
- ii)
- full motion video,
- .LP
- iii)
- transparent flow,
- .LP
- IV
- telex.
- .sp 1P
- .LP
- 2.2
- \fIControl and user planes\fR
- .sp 9p
- .RT
- .PP
- The support of out\(hyof\(hyband signalling and the ability to activate
- supplementary services during the active phase of the call imply a separation
- between control information and user information.
- .PP
- The notion of plane\ \(em\ control plane, or C\(hyplane, and user plane,
- or U\(hyplane\ \(em\ is introduced to reflect this.
- .PP
- The main rationale for protocols within the user plane is the
- transfer of information among user applications, e.g. digitized voice,
- data and information transmitted between users. This information may be
- transmitted
- transparently through an ISDN, or it may be processed or manipulated,
- e.g.\ A/\(*m law conversion.
- .PP
- The main rationale for protocols within the control plane is the
- transfer of information for the control of user plane connections,
- e.g.\ in:
- .RT
- .LP
- \(em
- controlling a network connection (such as establishing and
- clearing down);
- .LP
- \(em
- controlling the use of an already established network
- connection (e.g.\ change in service characteristics during a
- call such as alternate speech/unrestricted
- 64\ kbit/s);
- .LP
- \(em
- providing supplementary services.
- .PP
- \fR In addition to user information, any information which controls
- the exchange of data within a connection, but otherwise does not alter the
- state of this connection (e.g.\ flow control), pertains to the U\(hyplane. All
- control information which involves resource allocation/deallocation by
- the ISDN pertains to the C\(hyplane.
- .sp 1P
- .LP
- 2.3
- \fILocal and global significance\fR
- .sp 9p
- .RT
- .PP
- A key characteristic of the ISDN is that, due to the integration of telecommunication
- services, the facilities to be provided depend on whether the adjacent
- entity, or a remote entity, is involved: different services, possibly using
- different routes, may have to be provided accordingly. An example is a
- telecommunication service, which can be supported by various network
- capabilities, (e.g.\ a telematic service supported either by circuit or
- packet facilities), or an ISDN connection based on various types of basic
- connection components (e.g.\ analogue and digital circuits for a speech
- connection).
- .bp
- .PP
- As a consequence, the control information handled by an entity may
- concern:
- .RT
- .LP
- \(em
- an adjacent functional entity, in which case it is said to
- have local significance;
- .LP
- \(em
- a remote (non\(hyadjacent) functional entity, in which case it has global
- significance.
- .PP
- The significance concept is illustrated by Figure 2/I.320
- .PP
- The notion of significance applies to control plane information
- only. As an example from the ISDN user's point of view:
- .RT
- .LP
- \(em
- the overall service to be provided to users has a
- global significance;
- .LP
- \(em
- the control of any resources to be used at the user\(hynetwork interface
- has local significance;
- .LP
- and, from the network's point of view:
- .LP
- \(em
- the overall service to be provided by the ISDN (ISDN
- connection types, as introduced in Recommendation I.340) has a global
- significance;
- .LP
- \(em
- the handling of connection elements has local
- significance.
- .LP
- .rs
- .sp 16P
- .ad r
- \fBFigure 2/I.320, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- Depending on their functional requirements, supplementary services relate
- to either the local, or global perspective. For example:
- .LP
- \(em
- completion of calls to busy subscribers (CCBS) or
- user\(hyto\(hyuser signalling (UUS) have global
- significance;
- .LP
- \(em
- call waiting has local significance.
- .PP
- Global information falls into three classes:
- .LP
- 1)
- the information is transported transparently;
- .LP
- 2)
- the information may be processed, but remains
- unchanged (e.g.\ teleservice);
- .LP
- 3)
- the information may be altered (e.g. destination number
- in relation with freephone or call forwarding supplementary
- services).
- .sp 2P
- .LP
- \fB3\fR \fBModel\fR
- .sp 1P
- .RT
- .PP
- The ISDN PRM is represented by a
- protocol block
- which
- incorporates the concepts of layer, significance and plane described
- above.
- .PP
- Such a protocol block can be used to describe various elements in the ISDN
- user premises and the network [e.g.\ terminal equipment (TE), ISPBX network
- termination (NT), exchange termination (ET), signalling point (SP) and
- signalling transfer point (STP), etc.].
- .bp
- .RT
- .sp 1P
- .LP
- 3.1
- \fIGeneric protocol block\fR
- .sp 9p
- .RT
- .PP
- The considerations above lead to the introduction of the concept
- of significance in combination with planes; the result is a splitting of the
- control plane into two parts: a local control (LC) plane, and a global
- control (GC) plane, in addition to the user (U) plane.
- .PP
- The layering principles apply in each of these planes: each plane can potentially
- accommodate a 7\(hylayer stack of protocols. A
- plane management
- function
- is required to allow coordination between the activities in the
- different planes. Examples of plane management function are:
- .RT
- .LP
- \(em
- the decision on whether an incoming information is relevant to the LC\(hy
- or GC\(hyplane,
- .LP
- \fR \(em
- allowing communication between C\(hy and U\(hyplanes, for
- synchronization purposes.
- .PP
- The Generic protocol block is represented in
- Figure 3/I.320.
- .PP
- \fINote\fR \ \(em\ The plane management function should not be confused
- with the system management as introduced to model OSI
- management.
- .PP
- The following remarks apply:
- .RT
- .LP
- 1)
- Some layers may be empty, i.e. they provide no
- functionality. For example, it is likely that not all
- seven layers are required to serve the LC\(hyplane requirements;
- however, entities communicating in this plane are application
- layer entities. Note that this is not in contradiction with
- the OSI\ RM.
- .LP
- 2)
- An element (either in the network, or in user premises)
- does not have to support in all cases protocols of LC\(hy, GC\(hy
- and U\(hyplanes: some may ignore one or even two of these
- planes. For example, a network service centre accessed to provide a
- supplementary service (e.g.\ freephone) will be concerned
- by the LC\ plane only, and will have no knowledge of the
- other two planes.
- .LP
- 3)
- A network element\ \(em\ unless it provides a high layer function (HLF)\
- \(em\ will generally not support any U\(hyplane
- protocol above layer 3.
- .LP
- 4)
- The need for application processes specific to each
- plane, or for application processes able to access several planes, is
- for further study.
- .LP
- .rs
- .sp 27P
- .ad r
- \fBFigure 3/I.320, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- 3.2
- \fIRelations between layers in one plane\fR
- .sp 9p
- .RT
- .PP
- Adjacent layers within a plane communicate using service
- primitives. If a layer is empty the primitive is mapped directly onto a
- primitive to the next layer.
- .PP
- Further study is required on which layer services have to be specified
- in order to describe a telecommunication service.
- .RT
- .sp 1P
- .LP
- 3.3
- \fIRelations between planes\fR
- .sp 9p
- .RT
- .PP
- Starting from GC\(hyplane requirements, an entity will derive the
- LC\(hyplane requirements, and the facilities that have to be provided for the
- support of U\(hyplane lower layers. For example, in order to provide an ISDN
- connection (GC\(hyplane), an exchange will have to identify the required basic
- connection component (LC\(hyplane).
- .PP
- This relation is made via the plane management function.
- .PP
- Informations in different planes need not be carried by distinct
- physical/logical means in all cases. For example:
- .RT
- .LP
- \(em
- control and user information may use the same
- support, e.g.\ when in\(hyband signalling is used, or
- when user information is carried on a
- D\(hychannel;
- .LP
- \(em
- LC and GC information share the same support
- when the LC\(hyplane pass\(hyalong facility
- is used;
- .LP
- \(em
- ISPBX\(hyto\(hyISPBX control information appears as U\(hyplane
- information to the ISDN.
- .sp 1P
- .LP
- 3.4
- \fIData flow modelling\fR
- .sp 9p
- .RT
- .PP
- For further study.
- .RT
- .sp 2P
- .LP
- \fB4\fR \fBISDN management\fR
- .sp 1P
- .RT
- .PP
- For further study.
- .RT
- .sp 2P
- .LP
- \fB5\fR \fBInterworking\fR
- .sp 1P
- .RT
- .PP
- A number of particular interworking situations should be
- considered:
- .RT
- .LP
- \(em
- internetworking with an OSI network;
- .LP
- \(em
- interworking with an non\(hyISDN terminal;
- .LP
- \(em
- interworking between two ISDNs which do not provide the
- same set of facilities;
- .LP
- \(em
- interworking involving a network\(hyprovided
- interworking function to support high\(hylayer and/or
- low\(hylayer facilities.
- .sp 1P
- .LP
- 5.1
- \fIGeneral\fR
- .sp 9p
- .RT
- .PP
- All the interworking situations mentioned above are covered by the model
- illustrated by Figure 4/I.320.
- .PP
- The service S may be:
- .RT
- .LP
- \(em
- the initially required telecommunication service (TS),
- if both networks are able to provide it (F is then
- empty);
- .LP
- \(em
- a telecommunication service resulting from a negotiation
- process, which both networks are able to provide (F is then
- empty);
- .LP
- \(em
- a service which is required to support the
- telecommunication service to be provided, which is offered
- by both networks, but by means of different capabilities in
- the two networks.
- .PP
- The service S is provided:
- .LP
- \(em
- by means of functions F1 and protocol(s) P1 in
- network\ 1;
- .LP
- \(em
- by means of functions F2 and protocol(s) P2 in
- network\ 2.
- .PP
- The interworking function (IWF) maps the facilities offered by F1 and F2.
- .bp
- .LP
- .rs
- .sp 24P
- .ad r
- \fBFigure 4/I.320, (N), p. 13\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- Two kinds of interworking can take place:
- .RT
- .LP
- 1)
- a one\(hystage interworking, where the calling user is not
- explicitly aware that an interworking function is
- required;
- .LP
- 2)
- a two\(hystage interworking, where the calling user has a
- dialogue with the interworking function prior to
- exchanging control information with the destination
- user.
- .PP
- The model applies to both cases.
- .PP
- Interworking may involve the GC\(hyplane, and/or the U\(hyplane.
- .PP
- In an interworking situation, the GC\(hyplane has to:
- .RT
- .LP
- \(em
- determine the telecommunication service to be provided
- (agreed telecommunication service): this may imply service
- negotiation;
- .LP
- \(em
- identify the interworking situation, i.e. the fact that
- more than one network is involved, and that for some
- service\ S required to support the telecommunication
- service, two adjacent networks do not use the same underlying
- facilities;
- .LP
- \(em
- locate and invoke an IWF capable of mapping the facilities
- in the two networks.
- .PP
- In each network, the GC\(hyplane facilities will provide the
- functions and protocols (Fi and Pi) required to support service\ S; this will
- result in different (and independent) requirements on the LC\(hyplane in each
- network.
- .PP
- In the two\(hystage interworking case, the GC\(hyplane information is
- \*Uconsumed\*U by the IWF during the first phase, and is forwarded (with
- or without modification) during the second phase.
- .PP
- Whenever interworking in the U\(hyplane is involved, the following
- differences apply in the two cases:
- .RT
- .LP
- \(em
- one\(hystage interworking: in this case only the
- first three layers (at most) may be involved for the provision
- of the requested end\(hyto\(hyend service. No HLF is
- required.
- .LP
- \(em
- two\(hystage interworking: in this case the first stage is the establishment
- of the U\(hyplane facilities between the calling
- user and the IWF. High layer functions (HLF) and protocols
- may be involved, in which case the IWF acts as a substitute
- for the called user.
- .bp
- .sp 1P
- .LP
- 5.2
- \fIRelationships with the OSI RM\fR
- .sp 9p
- .RT
- .PP
- The OSI RM, seen from the ISDN PRM point of view, appears not to
- be in contradiction with the latter, but contains some restrictions which
- stem from the fact that it does not have the same scope:
- .RT
- .LP
- 1)
- The C\(hy and U\(hyplanes are not separated, since the C\(hy and
- U\(hyplane information in one layer (\fIn\fR ) always maps onto the U\(hyplane
- information of the layer below (\fIn\fR \ \(em\ 1).
- .LP
- 2)
- The concept of significance does not explicitly appear;
- however control informations (e.g.\ in layer 3) include both \*Qlocal\*U
- informations and informations which are carried end\(hyto\(hyend transparently
- or
- take part in the definition of the overall service provided to the user
- (e.g.\ throughput).
- .LP
- 3)
- The C\(hy and U\(hyplane informations in one layer (\fIn\fR ) map onto
- the U\(hyplane informations of the layer below (\fIn\fR \ \(em\ 1).
- .PP
- Interworking between the OSI RM and ISDN PRM takes place in the
- following situations:
- .LP
- \(em
- internetworking with a specialized network (e.g. PSPDN)
- which respects the OSI RM: the reference points involved
- are K/L;
- .LP
- \(em
- interworking with an \*QOSI terminal\*U via a terminal adaptor:
- the reference point is then R;
- .LP
- \(em
- the interworking of an ISDN terminal on the S reference
- point which conforms to the OSI reference model is for
- further study.
- .PP
- In each case, the interworking function (an IWF or a TA)
- has to map information flows of one model onto information flows of the
- other.
- .sp 1P
- .LP
- 5.2.1
- \fIInterworking at reference point K/L\fR
- .sp 9p
- .RT
- .PP
- For further study.
- .RT
- .sp 1P
- .LP
- 5.2.2
- \fIInterworking at reference point R\fR
- .sp 9p
- .RT
- .PP
- In the case when a user application, running an OSI system,
- requires network services across the ISDN, the originating user application
- will address the terminating application as a destination user.
- .PP
- In the OSI system, the application is considered as an ISDN user \(em
- a communicating functional entity in the PRM.
- .PP
- The GC information pertinent to the higher layer OSI application
- is carried in the U\(hyplane to the destination application. The GC information
- pertinent to the network service required is carried in the C\(hyplane with
- LC information.
- .PP
- The OSI system requests the network service from the ISDN by placing a
- service request to both the LC\(hyplane and the U\(hyplane (Figure 5/I.320).
- The
- distribution of the information to the appropriate planes is made by the
- plane management function
- . The plane management function is responsible for providing an OSI service
- access point to the OSI system.
- .RT
- .sp 2P
- .LP
- \fB6\fR \fBExamples\fR
- .sp 1P
- .RT
- .PP
- Applications of the PRM to the following examples is for further
- study.
- .RT
- .sp 1P
- .LP
- 6.1
- \fIBasic call situations\fR | (no supplementary service,
- no interworking)
- .sp 9p
- .RT
- .PP
- \(em
- circuit service (see Figure\ 6/I.320)
- .RT
- .LP
- \(em
- packet service
- .LP
- \(em
- multi\(hybearer capability
- .LP
- \(em
- data base access.
- .bp
- .LP
- .rs
- .sp 18P
- .ad r
- \fBFigure 5/I.320, (N), p. 14\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .rs
- .sp 18P
- .ad r
- \fBFigure 6/I.320, (N), p. 15\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- 6.2
- \fIMore elaborate situations\fR
- .sp 9p
- .RT
- .PP
- \(em
- supplementary services:
- .RT
- .LP
- \(em
- completion of calls to busy subsribers (CCBS);
- .LP
- \(em
- three\(hyparty service;
- .LP
- \(em
- PABX facilities;
- .LP
- \(em
- OAM (operational, administrative and maintenance)
- applications.
- .bp
- .sp 1P
- .LP
- 6.3
- \fIInterworking\fR
- .sp 9p
- .RT
- .PP
- \(em
- at reference point R (Teletex terminal):
- .RT
- .LP
- \(em
- with a PSTN;
- .LP
- \(em
- with a PSPDN (Videotex);
- .LP
- \(em
- inside an ISDN (provision of an HLF by the network);
- .LP
- \(em
- of public ISDN with other networks (a possible example is
- given in Figure\ 7/I.320).
- .LP
- .rs
- .sp 25P
- .ad r
- \fBFigure 7/I.320, (N), p.\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .EF '% Fascicle\ III.8\ \(em\ Rec.\ I.324''
- .OF '''Fascicle\ III.8\ \(em\ Rec.\ I.324 %'
- .LP
- .rs
- .sp 18P
- .sp 2P
- .LP
- \fBMONTAGE:\ \ \fR Rec. I.324 sur le reste de cette page
- .sp 1P
- .RT
- .LP
- .bp
-