1、RECMN*Q-L204 73 48b257L 0582877 37b INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Q.1204 (03/93) GENERAL RECOMMENDATIONS ON TELEPHONE SWITCHING AND SIGNALLING INTELLIGENT NETWORK INTELLIGENT NETWORK DISTRIBUTED FUNCTIONAL PLANE ARCHITECTURE ITU-T Recomme
2、ndation Q.1204 (Previously “CCIlT Recommendation“) ITU-T RECMN*Q*1204 93 H 48b259L 0582880 098 H I FOREWORD I The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of the International Telecom- munication Union. The ITU-T is responsible for studying technical, operating and t
3、ariff questions and issuing I Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, established the topics for study by the ITU-T Study Groups which, in their turn, pr
4、oduce Recommendations on these topics. ITU-T Recommendation Q.1204 was prepared by the ITU-T Study Group XI (1988-1993) and was approved by the WTSC (Helsinki, March 1-12, 1993). NOTES 1 As a consequence of a reform process within the International Telecommunication Union (ITU), the CCIT ceased to e
5、xist as of 28 February 1993. In its place, the ITU Telecommunication Standardization Sector (ITU-T) was created as of 1 March 1993. Similarly, in this reform process, the CCIR and the IFRB have been replaced by the Radiocommunication Sector. In order not to delay publication of this Recommendation,
6、no change has been made in the text to references containing the acronyms ?CCITT, CCIR or IFRB? or their associated entities such as Plenary Assembly, Secretariat, etc. Future editions of this Recommendation will contain the proper terminology related to the new ITU structure. 2 telecommunication ad
7、ministration and a recognized operating agency. In this Recommendation, the expression ?Administration? is used for conciseness to indicate both a o ITU 1993 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, includin
8、g photocopying and microfilm, without permission in writing from the ITU. . m . m I CONTENTS General Distributed funtional plane model 2.1 Explanation of dia gtam . 2.3 Definition of functional entities related to IN service execution . 2.4 Definition of IN service creatidmanagement related function
9、al entities Functional entity calYservice logic processing models 3.1 General . 3.2 Modelling objectivedcriteria . 3.3 General assumptions . 3.4 Overview of calkervice logic processing related functional entities 3.5 CNservice logic processing functional entity models . Relationship between function
10、al en titi. . 4.1 General . 4.2 Relationships 4.3 Information flows between functional entities . 5.1 Mapping requirements 5.2 5.3 Mapping the global functional plane to the distributed functional plane . Relationship to IN conceptual model . An example of mapping some selected SLBs to functional en
11、 tities . Annex A . Example basic call state model (BCSM) . A.l General . A.2 Example BCSM description Annex B - Object-oriented finite state machine modelling Annex C - Call segment model Call segment model components . LocaVglobal SCF view of identifying study subjects for the modelling of functio
12、nal entities related to IN-supported Mservice logic processing to determine the nature of the relationships between them; and providing tools for the modelling of functional entities in a manner consistent with IN objectives, as appropriate for a given CS. While the IN DFP architecture and modelling
13、 tools in this Recommendation have proven extremely useful in processing IN standardization, they do not necessarily represent an ultimate view of IN evolution. As such, this Recommendation represents a current understanding that may require future enhancements as the ultimate view of IN is refined.
14、 Within the Q.120-Series Recommendations, this Recommendation describes the distribution of global functional plane functionality defined in Recommendation 1.329/Q. 1203 (i.e. service independent building blocks) in a service and vendorhplementation independent manner. This provides the flexibility
15、to allocate distributed functionality into multiple physical network configurations, as described in Recommendation Q. 1205, and to evolve IN from an initial CS (e.g. CS-1) to some future CS-n. It also provides a framework from which IN protocols are specified, as described in Recommendation Q.1208.
16、 - - 11 Recommendation Q.1204 (03/93) ITU-T RECMN*d-1204 93 W 4862591 0582883 8T7 W Recommendation Q.1204 INTELLIGENT NETWORK DISTRIBUTED FUNCTIONAL PLANE ARCHITECTURE (Helsinki, 1993) 1 General The requirements and assumptions for the IN distributed functional plane (DFP) architecture are as follow
17、s: a) The DFP architecture is consistent with the framework defined by the IN conceptual model: - it identifies the specific elements and the relationship between them that are necessary to support the objectives of IN; - The DFP architecture provides the flexibility to support a large variety of se
18、rvices and facilitates the evolution of IN by organizing the functional capabilities in an open-ended and modular structure to achieve service independence. The DFP architecture is vendorhplementation independent, thereby providing the flexibility for multiple physical networking configuration and p
19、lacing no constraints on national network architecture beyond the network and interface standards which will be developed for IN structured networks. The definition of the DFP architecture initially accommodates service execution capabilities and will accxnnmodate service creation and service and ne
20、twork management capabilities when they become available. the DFP architecture models the functions to be performed in IN structured networks. b) c) d) 2 Distributed funtionai plane model Figure 2-1 identifes the IN DFP model. 2.1 Explanation of diagram 2.1.1 Functional entities A functional entity
21、is a unique group of functions in a single location and a subset of the total set of functions required to provide a service. One or more fiinctional entities can be located in the same physical entity. Different functional entities contain different functions, and may also contain one or more of th
22、e same functions. in addition, one functional entity Cannot be split between two physical entities; the functional entity is mapped entirely within a single physical same physical entity. I I j I entity. Finally, duplicate instances of a functional entity can be mapped to different physical entities
23、, though not the Functional entities are represented by ovais in the functional model diagram. Functional entities are assigned unique FUNCONAL, ENTITY IDENTIFIERS (e.g. CCF, for call control function). Functional entity descriptions do not include utilityhousekeeping functions which are not directl
24、y involved in providing a service. This explains why there is no functional entity identified to describe the communication between functional entities. The physical location of a function is not the only criteria for grouping functions into a functional entity. Functional entity grouping criteria s
25、hould take into consideration ali technological and business requirements. Recommendation Q.1204 (0-3) 1 ITU-T RECNN*Q-tion Service management access function Service management function Specialised resource fuxh Cmce switching function NOTES 1 2 The two SSFKCF have identical functionality and are o
26、nly shown for some procedures like assist. The definitions of CCAF and CCF are based on corresponding 4.71 ISDN deinitions, but may be modified for,use in IN. FIGW 2-1/4.1204 IN distributed functional plane model 2.1.2 Relationships Each interaction between a communicating pair of functional entitie
27、s in the model is termed an “information flow”. The relationship between any communicating pair of functional entities in the model is defined by a set of information flows. Functional entity relationships are the lines between functional entities in the functional model diagram. Relationships may h
28、ave TYPE identifiers assigned, which uniquely identify specific sets of information flows within the model (e.g. rl, 12, etc.). The same relationship type may occur more than once in a functional model. 2 Recommendation Q.1204 (03/93) ITU-T RECMN*.3204 93 M 4862593 0582885 b7T = If the model does no
29、t show a line between functional entities, there is no identified relationship which requires standardization between them. If a communicating pair of functional entities is located in physically separate entities, the relationship between them defmes the information transfer requirements for a prot
30、ocol between the physical entities. 2.3 Definition of functionai entities related to IN service execution The CCA function (CCAF): The CCAF is the call control agent (CCA) function that provides access for users. It is the interface between user and network call control functions. It a) provides for
31、 user access, interacting with the user to establish, maintain, modify and release, as required, a ca or instance of service; b) accesses the service-providing capabilities of the call control function (CO, using service requests (e.g. setup, transfer, hold, etc.) for the establishment, manipulation
32、 and release of a call or instance of service; c) receives indications relating to the call or service from the CCF and relays them to the user as required; d) maintains cali/service state information as perceived by this functional entity. The CC function (CCF): The CCF is the call control (CC) fun
33、ction in the network that provides calikonnection processing and control. It a) b) establishes, manipulates and reieases callkonnection instances as “requested“ by the CCAF; provides the capability to associate and relate CCAF functional entities that are involved in a particular call and/or connect
34、ion instance (that may be on SSF requests); manages the relationship between CCAF functional entities involved in a call (e.g. supervises the overall perspective of the call and/or connection instance); provides trigger mechanisms to access IN functionality (e.g. passes events to the SSF); is manage
35、d, updated and/or otherwise administered for its IN-related functions (i.e. trigger mechanisms) by a service management function (SW. c) d) e) The SS function (SSF): The SSF is the service switching (SS) function, which, associated with the CCF, provides the set of functions required for interaction
36、 between the CCF and a service control function (SCF). It a) extends the logic of the CCF to include recognition of service control triggers and to interact with the SCF; b) manages signalling between the CCF and the SCF; c) modifies Calllconnection processing functions (in the CCF) as required to p
37、rocess requests for IN provided service usage under the control of the SW, is managed, updated and/or otherwise administered by an SMF. d) The SC function (SCF): The SCF is a function that commands call control functions in the processing of IN provided and/or custom service requests. The SCF may in
38、teract with other functional entities to access additional logic or to obtain information (service or user data) required to process a cali/service logic instance. It a) interfaces and interacts with service switching functiond control function, specialized resource function (SW and service data fun
39、ction (SDF) functional entities; b) c) d) contains the logic and processing capability required to handle IN provided service attempts; interfaces and interacts with other SCFs, if necessary; is managed, updated and/or otherwise administered by an SMF. Recommendation Q.1204 (03/93) 3 ITU-T RECMN*Q=1
40、204 93 W 48b2591 0582886 506 The SD function (SDF): The SDF contains customer and network data for real time access by the SCF in the execution of an IN provided service. It a) b) c) NOTE - The SDF contains data relating directly to the provision or operation of IN provided services. Thus it does no
41、t interfaces and interacts with SCFs as required; interfaces and interacts with other SDFs, if necessary; is managed, updated and/or otherwise administered by an SMF. necessarily encompass data provided by a third party such as credit information, but may provide access to these data. The SR functio
42、n (SRF): The SRF provides the specialized resources required for the execution of IN provided services (e.g. digit receivers, announcements, conference bridges, etc.). It a) b) c) interfaces and interacts with SCF and SSF (and with the CCF); is managed, updated and/or otherwise administered by an SM
43、F; may contain the logic and processing capability to receive/send and convert information received from users; d) may contain functionality similar to the CCF to manage bearer connections to the specialized resources. 2.4 Definition of IN service creatiodmanagement related functional entities servi
44、ce creation environment function (SCEF): This function allows services provided in an intelligent network to be defined, developed, tested and input to SMF. Output of this function would include service logic, service management logic, service data template and service trigger information. service m
45、anagement access function (SMAF): This function provides an interface between service managers and the SMF. It aows service managers to manage their services (through access to the SMF). service management function (SMF): This function allows deployment and provision of IN provided services and allo
46、ws the support of ongoing operation. Particularly, for a given service, it allows coordination of different SCF and SDF instances, e.g.: - billing and statistic information are received from the SCFs, and made available to authorized service managers through the SMAF, modifications in service data a
47、re distributed in SDFs, and it keeps track of the reference service data values. - The SMF manages, updates and/or administers service related information in SRF, SSF and CCF. NOTE - The relation between TMN (see Recommendation M.30), SMAF and SMF is for further study. 3 Functional entity call/servi
48、ce logic processing models 3.1 General IN call/service logic processing encompasses call and connection processing in the SSFKCF, service logic execution in the SCF, and the use of supporting resources and data in the SRF and SDF, respectively. This subclause describes this IN callhervice logic proc
49、essing in terms of call modelling and modelling of service logic processing. - Call modelling provides a high-level service and vendorhnplementation independent abstraction of IN call and connection processing in the SSF and CCF. This abstraction provides an observable view of SSFICCF activities and resources to the SCF, enabling the SCF to interact with the SSF in the course of executing service logic. 4 Recommendation Q.1204 (03/93) ITU-T RECMN*QeL20Y 93 4862591 0582887 4Y2 = - The modelling of service logic processing provides an abstraction of SCF activities and resources needed
