1、D 3404583 00bb74b TT9 - 1- kTSI 1 ECHNICAL REPORT ETR 023 June 1991 UDC: 621.395, 654.1 Key words: Telephone networks, intelligent networks Network aspects Intelligent Networks: Framework ETSI European Telecommunications Standards Institute ETSI Secretariat Postal address: 06921 Sophia Antipolis Ced
2、ex - FRANCE Office address: Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE Tel.: + 33 92 94 42 O0 - Fax: + 33 93 65 47 16 - Tlx: 470 040 F European Telecommunications Standards Institute 1 99 1 . All rights reserved. No part may be reproduced or used except as authorised by contract or ot
3、her written permission. The copyright and the foregoing restriction on reproduction and use extend to all media in which the information may be embodied. 3404583 00bb747 935 W Page 2 ETR 023:1991 Whilst every care has been taken in the preparation and publication of this document, errors in content,
4、 typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to “ETSI Standards Management Dept.“ at the address shown on the title page. 3404583 0066748 87L Contents Page 3 ETR 023:1991 Foreword 7 Objectives and scope of the Intelligent Network (IN) framework d
5、ocument . 9 Objectives. scope and definition of IN . 9 1.1 Motivation. requirements and modelling concepts . 9 1.1.1 Motivation . 9 1.1.2 Objectives of IN 9 1.1.3 ScopeofIN 9 1.2 Definition of IN 10 1.3 Evolution of IN 10 1.4 Relationship with CCITT studies . 11 1.5 Relationship with other ETSI stud
6、ies 12 1.6 Workplan 12 IN functional requirements 13 2.1 Introduction 13 2.2 Service requirements 14 2.2.1 Overall requirements 14 2.2.2 Service creation . 15 2.2.3 Service management 15 2.2.3.1 Service deployment 15 2.2.3.2 Service provisioning management . 15 2.2.3.3 Service control management . 1
7、6 2.2.3.4 Billing . 16 2.2.3.5 Service monitoring . 16 2.2.4 Service processing . 16 2.3 Network requirements . 18 2.3.1 Overall requirements 18 2.3.2 Service creation . 19 2.3.3 Service management 21 2.3.3.1 Service deployment 21 2.3.3.2 Service provisioning 21 2.3.3.3 Service control . 21 2.3.3.4
8、Billing . 21 2.3.3.5 Service monitoring . 22 2.3.4 Network management . 22 2.3.5 Service processing . 23 2.3.6 Network interworking . 26 2.3.6.1 Gateway functions for service processing 27 2.3.6.2 Gateway functions for service management . 28 2.3.6.3 Gateway functions for service creation 28 IN arch
9、itecture . 28 3.1 Requirements and assumptions 28 3.2 The IN conceptual model 29 3.2.1 Service plane 30 3.2.2 Global functional plane 30 3.2.3 Distributed Functional Plane (DFP) . 30 3.2.4 Physical plane 30 3.2.5 Relationship with the 3 stage method 30 3.2.6 Service logic . 30 3.2.7 Relationships am
10、ong different planes . 31 3.2.8 Service interaction . 31 3.2.9 Service and network interworking . 31 3.2.1 O Management functionality 31 3.3 OAM . 32 3.4 Service plane architecture . 33 3.4.1 General 33 3.4.2 Characterisation of services and service capability requirements . 33 3.4.3 Service interac
11、tion . 34 3.4.4 Service plane modelling 35 3.4.5 Mapping of requirements . 35 m 3404583 0066749 708 m Page 4 ETR 023: 1991 3.5 Global functional plane architecture 35 3.5.1 General . 35 3.5.2 Global functional plane modelling 36 3.5.2.1 Identification of SIBs . 36 3.5.2.2 Classification of SIBs 38 3
12、.5.2.3 SIBs description methodology . 38 3.5.3 Mapping of requirements 45 Distributed functional plane architecture . 45 3.6.1 Introduction 45 3.6.1.1 Requirements and assumptions 45 3.6.1.2 Definitions . 45 3.6.2 Distributed functional plane modelling . 46 3.6.2.1 Overview of the IN functional arch
13、itecture 46 3.6.2.2 Description of FES (step 1) . 47 control access function . 47 3.6.2.2.1.1 Definition 47 3.6.2.2.1.2 Description . 48 3.6.2.2.1.3 Functions performed . 48 3.6.2.2.1.4 Relationships 51 3.6.2.2.2 Specialised resource function . 51 3.6.2.2.2.1 Definition 51 3.6.2.2.2.2 Description .
14、51 3.6.2.2.2.3 Functions performed . 52 3.6.2.2.2.4 Relationship 52 3.6.2.2.3 Service control function . 54 3.6.2.2.3.1 Definition 54 3.6.2.2.3.2 Description . 54 3.6.2.2.3.3 Functional performed 54 3.2.2.3.4 Relationships 56 3.6.2.2.4 Specialised database function (SDF) . 57 3.6.2.2.4.1 Definition
15、57 3.6.2.2.4.2 Description . 57 3.6.2.2.4.3 Functions performed . 57 3.6.2.2.4.4 Relationships 58 3.6.2.2.5 Service creation environment function . 58 3.6.2.2.5.1 Definition 58 3.6.2.2.5.2 Description . 58 3.6.2.2.5.3 Functions performed . 58 3.6.2.2.6.1 Definition 59 3.6.2.2.6.2 Description . 59 3.
16、6.2.2.6.4Relationships 60 3.6.2.2.7 Service management function . 60 3.6.2.2.7.1 Definition 60 3.6.2.2.7.2 Description . 60 3.6.2.2.7.3 Functions performed . 61 3.6.2.2.7.4 Relationships 64 3.6.3 Overall call modelling 65 specification 65 execution 66 3.6.4 Overall call modelling 67 3.6.5 Connection
17、 Control Model (CCM) 67 3.6.5.1 General . 67 3.6.5.2 CCM Objectives/Criteria . 67 3.6.5.3 General assumptions . 67 3.6.5.4 Proposed model 68 3.6.6 Examples of Call Configuration 68 4 I.N. terminology 68 4.1 Principles . 68 4.2 I.N. terminology glossary 70 3.6 3.6.2.2.1 Service switching function / c
18、onnection control function / call 3.6.2.2.5.4 Relationships 59 3.6.2.2.6 Service Management Agent Function (SMAF) . 59 3.6.2.2.6.3 Functions performed . 59 3.6.3.1 Requirements on the model to be used for service 3.6.3.2 Requirements on the model to be used for service 3404583 0066750 42T Annex A (i
19、nformative): Workplan . 76 A.l IN work plan . 76 A.1.1 Definition of capability sets 76 A.1.2 Scope and objectives 76 A.1.3 General considerations on the standardisation process 76 A.1.4 Standards areas . 77 A . 1.5 Phased standardisation . 79 Annex B (informative): Overall call modelling 80 Annex C
20、 (informative): Connection control model 83 C.l General 83 . C.2 Connection control modelling C.2.1 Environment C.2.2 The socket . C.2.3 Multiple sockets . C.2.4 Logical objects and socket types C.2.5 Components of the connection control model C.2.6 The connection control socket model C.2.7 Virtual
21、switch concept/connection segment . C.2.8 Basic call segments . C.2.9 Feature segment . C.2.1 O Separation of logical and physical connectivity C.2.11 Feature interaction management . C.2.12 The relationship between the basic call model and the connection segment relationship model . 83 83 84 84 85
22、85 86 87 87 88 89 89 90 C.3 Definitions relating to the connection control model . 91 C.4 Socket behaviour 95 C.4.1 Requirements . 95 C.4.2 Modelling principles . 95 C.4.3 Outline of common socket services . 96 C.4.4 Socket type specific services . 97 C.4.5 Sequencing of services . 97 C.4.6 Mapping
23、onto other services . 97 C.5 Connection control socket 97 C.5.1 Opening and closing of the socket . 97 C.5.1.1 Socket opening . 97 C.5.1.2 Socket closing 99 C.5.1.3 Socket test 99 C.5.2 Objects in the connection control socket . 99 C.5.2.1 Leg . 100 C.5.2.2 Connection point 101 C.5.3 Service primiti
24、ves 101 C.5.4 Leg state representation 103 C.5.5 Connection point state representation . 105 C.6 Data Management (DM) socket . 105 C.6.1 Opening and closing the socket . 105 C.6.2 Objects in the socket 106 C.6.3 Service primitives 107 C.7 Status monitoring socket . 111 C.7.1 Opening and closing of t
25、he socket . 111 C.7.2 Objects in the socket 111 C.7.3 Service primitives related to the objects 111 C.8 Traffic management socket . 112 C.8.1 Opening and closing of the socket . 112 C.8.2 Objects in the socket 113 C.8.3 Primitives on the sockets . 113 C.9 Resource control socket . 114 C.9.1 Opening
26、and closing of the socket . 114 C.9.2 Objects in the socket 115 C.9.3 Service primitives related to the objects 115 C.1 O Requirements on the basic call model 116 C . 10.2 Call state transition requirements 117 Annex D (informative): Examples of call configuration 118 D.l Originating services during
27、 call set up 118 D.2 Terminating services during call set up 119 D.3 Creating a leg to an IP 119 D.4 Multi-party call (mid call trigger) 120 D.5 Call Waiting (Barge-In Trigger) . 121 D.6 “Monitoring“ services . 121 D.7 Multiple simultaneous services . 122 C.10.1 The basic call model versus the conne
28、ction control model 116 3404583 0066752 2T2 Page 7 ETR 023:1991 Foreword This ETSI Technical Report (ETR) has been produced by the Network Aspects (NA) Technical Committee of the European Telecommunications Standards Institute (ETSI). ETRs are informative documents resulting from ETSI studies, but w
29、hich are not suitable for adoption as formal standards (ETSs or I-ETSs). The present document is intended to set out a stable basis for the developments of Intelligent Network (IN) standards. It contains information regarding IN Concepts and Modelling: IN objectives, definition and scope IN overall
30、requirements IN conceptual model Service plane architecture Global functional plane architecture IN functional architecture (high level) IN call modelling (high level) OAM (high level) This ETR records the current status of study into IN within ETSI Sub-Technical Committee NA6 up to September 1990,
31、identifies the aspects which could be standardised, and outlines a workplan (Annex A). IN will be standardised in phases. The technical capabilities to be standardised in Phase 1 will be identified in a subsequent ETR. m 3404583 0066753 I137 m Page 9 ETR 023:1991 1 Objectives, scope and definition o
32、f IN 1.1 1.1.1 Motivation Motivation, requirements and modelling concepts The term IN (Intelligent Network) is used to describe an architectural concept for all telecommunica- tions networks. IN aims to ease the introduction of supplementary services” (UPT, Freephone. ) based on more flexibility and
33、 new capabilities. Currently, the subject of IN is motivated by the interests of telecommunications service providers to rapidly, cost effectively and differentially satisfy their existing and potential market needs for services. Also, these service providers seek to improve the quality and reduce t
34、he cost of networkkervice operations and management. Additionally, current trends in technology permit and demand greater degrees of intelligence, and freedom in the allocation of this intelligence in the telecommunications network. Factors permitting such intelligence include: advances in digital t
35、ransmission and switching, common channel signalling, distributed data processing, - data base management and expert systems. Other advances, for example the improved mobility derived from miniaturisation of electronic components, demand greater degrees of distributed functionality within and betwee
36、n service provider networks. 1.1.2 Objectives of IN The objective of IN is to allow the inclusion of additional capabilities to facilitate servicehetwork implementation independent provision of services in a multi-vendor environment. Service implementa- tion independence allows service providers to
37、define their own services independently of service specific development by equipment vendors. Network implementation independence allows network operators to allocate functionality and resources within their networks and to efficiently manage their networks independently of network implementation sp
38、ecific developments by equipment vendors. 1.1.3 Scope of IN Types of networks: IN is applicable to a wide variety of networks including: public switched telephone network (PSTN), mobile, packet switched public data network (PSPDN) and ISDN.The types of networks and services that will be supported wi
39、ll be identified in a subsequent ETSI Technical Report. A number of factors that may influence the scope of the work on IN were identified as: activities on ONP; network operator plans; industrial product offerings; market needs. The term supplementary service is applicable to both ISDNs and non-ISD
40、Ns (see Glossary) Previous page is blank rn 3404583 0066754 075 rn Page 10 ETR 023:1991 1.2 Definition of IN Intelligent Network (IN) is an architectural concept for the creation and provision of telecommunica- tions services which is characterised by: Extensive use of information processing techniq
41、ues; Efficient use of network resources; Modularisation of network functions; Flexible allocation of network functions among physical entities; Portability of network functions among physical entities; Standardised communication between network functions via service independent interfaces; Access to
42、 the process of composition of services through the combination of network function; Customer control of some of his specific service attributes; Standardised management of service logic. 1.3 Evolution of IN The specification and deployment of networks that meet all of the objectives and comply full
43、y with the definition of the target IN will take many years and will be the subject of a long term architecture study. A minimum set of criteria for identifying AN INITIAL STANDARDISATION PHASE could be identified. For instance: a distributed intelligence with unified network control, with service l
44、ogic and parameters controllable by the service provider, and specified with sufficient open-ended features so as to gracefully evolve or expand. One important open-ended feature may be the independence between service control capabilities and bearer networks, e.g. N-ISDN and B-ISDN. Identification
45、of the complete operative criteria set is a subject for further study. Even with such “minimum criteria“, it is recognised that to effectively plan evolution beyond the INITIAL PHASE, longer-term target architecture(s1 must be considered. However, with numerous technical and market uncertainties, lo
46、nger-term target architecture(s) are themselves likely to evolve. Of course, the smooth transition from current architectures to the INITIAL PHASE should be considered when specifying the INITIAL PHASE using existing Recommendations whenever possible. The evolution needs and attributes of IN, as lis
47、ted below, could constitute part of the complete operative criteria set: 11 1 21 31 I41 An essential attribute for IN evolution is the modularisation of functionality and information, thereby providing flexibility in its distribution while maintaining unified control giving a single integrated view.
48、 This will facilitate the introduction of new technology as transparently as possible, thus enhancing network performance consistent with quality of service and network integrity objectives; IN should facilitate cost-effective evolution from existing network bases in practical flexible phases; In th
49、e initial phaseb), network elements may exist that support a limited range of IN functions. This will enable networks to retain existing network equipment initially, while still taking advantage of IN capabilities; IN techniques will evolve and will be applicable to appropriate types of network. In its continuing evolution, IN will be capable of providing services with mobility functions, ISDN and B-ISDN based services, and circuit, packet and hybrid type services in monomedia and multimedia environments; m 3404583 00bb755 TO1 m Page 11 ETR 023: 199 1 51 61 i71 i81 91 i101 As IN evo
