ITU-T Q 1205-1993 Intelligent Network Physical Plane Architecture (Study Group XI) 10 pp《IN物理平台结构(第11研究组)10页》.pdf

1、 - CCITT RECMN*Q.L205 93 iM 4862593 0580884 95S-m INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Q.1205 GENERAL RECOMMENDATIONS ON TELEPHONE SWITCHING AND SIGNALLING INTELLIGENT NETWORK (03/93) INTELLIGENT NETWORK PHYSICAL PLANE ARCHITECTURE ITU-T Recomme

2、ndation Q.1205 (Previously “CCITT Recommendation”) CCITT RECAN*Qe1205 93 U 486259ai 0580885 895 FOREWORD The IT Telecommunication Standardization Sector (ITU-T) is a permanent organ of the International Telecom- munication Union. The IT-T is responsible for studying technical, operating and tariff q

3、uestions and issuing 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, produce Rec

4、ommendations on these topics. ITU-T Recommendation Q.1205 was prepared by the ITiJ-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 (IT), the CCITT ceased to exist as

5、of 28 February 1993. In its place, the IT 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, no change

6、 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 administrat

7、ion and a recognized operating agency. In this Recommendation, the expression “Administration” is used for conciseness to indicate both a O IT 1993 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocop

8、ying and microfilm, without permission in writing from the ITU. CONTENTS summary 1 General 2 Requirements and assumptions 2.2 Assumptions . 2.1 Requirements 3 Physical entities (PES) Mapping of functional entities to physical entities . Selection of underlying protocol platforms 5 User interfaces .

9、4 Mapping the distributed functional plane to the physical plane 4.1 4.2 Recommendation Q.1205 (03/93) Page ii 1 1 1 2 2 4 4 6 6 i SUMMARY This Recommendation describes the physical plane of the general IN architecture. The physical plane identifies different physical entities (PES), the allocation

10、of functional entities to PES, and the interfaces between the PES. Companion Recommendations include the Q. 120x- and Q. 12lx-Series Recommendations, especially Recommen- dation 4.1215 which describes the physical plane for IN capability set 1. The text in this Recommendation is considered to be sta

11、ble. ii Recommendation Q.1205 (03/93) CCITT RECMN*Q.LZOS 93 W 4862593 0580888 5T4 Recommendation 4.1205 INTELLIGENT NETWORK PHYSICAL PLANE ARCHITECTURE (Helsinki, 1993) 1 General This Recommendation describes the physical plane of the general IN architecture. IN physical plane information specific t

12、o CS-1 is contained in Recommendation Q.1215. The physical plane of the IN conceptual model identifies the different physical entities and the interfaces between these entities. The physical plane architecture should be consistent with the IN conceptual model. The IN conceptual model is a tool that

13、can be used to design the IN architecture to meet the foliowing main objectives: - service implementation independence; - network implementation independence; - vendor and technology independence. The 1.130 stage 3 service description methodology may be used (which includes the functional specificat

14、ion of the node and detailed description of the protocol between the nodes) in developing the physical plane architecture. 2 Requirements and assumptions 2.1 Requirements The key requirements of the physical plane architecture are: - - - the functional entities in the distributed functional plane ca

15、n be mapped onto the physical entities; one or more functional entities may be mapped onto the same physical entity; one functional entity cannot be split between two physical entities (Le. the functional entity is mapped entirely within a single physical entity); duplicate instances of a functional

16、 entity can be mapped to different physical entities, though not to the same physical entity; physical entities can be grouped to form a physical architecture; the physical entities may offer standard interfaces; vendors must be able to develop physical entities based on the mapping of functional en

17、tities and the standard interfaces; vendors must be able to support mature technologies and new technologies as they become available. - - - - - Recommendation Q.1205 (03/93) 1 CCTTT RECMN*Q-L205 93 A 48b259L 0580889 430 W 2.2 Assumptions The following assumptions are made for the development of the

18、 physical plane architecture: - the IN conceptual model is used as a tool to develop the IN physical architecture: - existing and new technologies can be used to develop the physical entities: - the specification of functional entities in the distributed functional plane and standard interfaces In t

19、he physical plane wil make the network vendor independent and service independent: - sufficient number of interfaces will be identified for support of services, service creation and OAM functions. 3 Physical entities (PES) This clause describes a selection of PES to support the general IN. That sele

20、ction is not intended to preclude or disallow the application of any other IN PE to support the general IN. a) Service switching point (SSP) In addition to providing users with access to the network (if the SSP is a local exchange) and performing any necessary switching functionality, the SSP allows

21、 access to the set of IN capabilities. The SSP contains detection capability to detect requests or IN services. t also contaifis capabilities to communicate with other PE(s) containing a service control function (SCF), such as a service control point (SCP), and to respond to instructions from the ot

22、her PE. Functionaly, an SSP contains a cal4 control function (CCF), a service switching function (SSF), and, if the SSP is a local exchange, a caii control agent function (CCAF). It also may optionally contain a service control function (SCQ, andor a specialized resource function (SRF), and/or a ser

23、vice data function (SDF). b Service control point (SCP) The SCP contains the service logic programs (SLPs) that are used to provide IN services, and may optionally contain customer data. Multiple SCPs may contain the same SLPs and data to improve service reliability and to facilitate load sharing be

24、hVVeen SCPs. Functionally, an SCP contains a service control function (SCF), and may optionally contain a service data function (SDF). The SCP can access data in an SDP either directly or through a signalling network. The SDP may be in the same network as the SCP, or in another network. The SCP can

25、be connected to SSPs, and optionally to IPS, through the signalling network. The SCP can also be connected to an IP via an SSP relay function. c) Service data point (SDP) The SDP contains data used by SLPs to provide individualized services. Functionally, an SDP contains a service data function. It

26、can be accessed directly by an SCP andor SMP, or through the signalling network. It can also access other SDPs in its own or other networks. 2 Recommendation Q.1205 (03/93) - CCITT RECMN*Q-LZOS 93 W 4862593 0510890 352 a Intelligent peripheral (IP) The IP provides special resources for customization

27、 of services, and supports flexible information interactions between a user and the network. Optionally, the switching matrix used to connect users to these resources may be accessible to external SLPs. Examples of possible special resources are (this list is not meant to be exhaustive): - customize

28、d and concatenated voice announcements; - synthesized voicdspeech recognition devices; - DTMF digit collection; - audio conference bridge; - information distribution bridge; - tone generator; - text to speech synthesis; - protocol converters. The IP contains the special resource function (SW, and op

29、tionally a service switching function/call control function (SSF/CC. This optional SSF/CCF is used to provide external access to the connections to the resources within the IP. The IP connects to one or more SSPs, and/or to the signalling network. An SCP can request an SSP to connect a user to a res

30、ource located in an IP that is connected to the SSP from which the service request is detected. An SCP can also request the SSP to connect a user to a resource located in an IP that is connected to another SSP. Adjunct (AD) The Adjunct PE is functionally equivalent to an SCP (Le. it contains the sam

31、e functional entities) but it is directly connected to an SSP. Communication between an Adjunct and an SSP is supported by a high speed interface. This arrangement may result in differing performance characteristics for an Adjunct and an SCP. The application layer messages are identical in content t

32、o those carried by the signalling network to an SCP. An Adjunct may be connected to more than one SSP and an SSP may be connected to more than one Adjunct. Senke node (SN) The SN can control IN services and engage in flexible information interactions with users. The SN communicates directly with one

33、 or more SSPs, each with a point-tu-point signalling and transport connection. Functionally, the SN contains an SCF, SDF, SRF, and an SSFKCF. This SSFKCF is closely coupled to the SCF within the SN, and is not accessible by external SCFs. In a manner similar to an Adjunct, the SCF in an SN receives

34、messages from the SSP, executes SLPs, and sends messages to the SSP. SLPs in an SN may be developed by the same service creation environment used to develop SLPs for SCPs and Adjuncts. The SRF in an SN enables the SN to interact with users in a manner similar to an IP. An SCF can request the SSF to

35、connect a user to a resource located in an SN that is connected to the SSP from which the service request is detected. An SCF can also request the SSP to connect a user to a resource located in an SN that is connected to another SSP. Recommendation Q.1205 (03/93) 3 CCITT RECRN*6l-3205 93 4862593 058

36、0893 O99 g) Service switching and control point (SSCP) The SSCP is a combined SCP and SSP in a single node. Functionally, it contains an SCF, SDF, CCAF, CCF, and SSF. The connection between the SCF/SDF functions and the CCAF/CCF/SSF functions is proprietary and closely coupled, but it provides the s

37、ame service capability as an SSP and SCP separately. This node may also contain SRF functionality, i.e. SRF as an optional functionality. The interfaces between the SSCP and other PES are the same as the interfaces between the SSP and other PES, and therefore will not be explicitly stated. h) Servic

38、e management point (SMP) The SMP performs service management control, service provision control, and service deployment control. Examples of functions it can perform are data base administration, network surveillaace and testing, network traffic management, and network data collection. Functionally,

39、 the SMP contains the service management function (SMF) and, optionally, the service management access function (SMAF) and the service creation environment function (SCEF). The SMP can access all other PES. i) Service creation environment point (SCEP) The SCEP is used to define, develop, and test an

40、 IN service, and to input it into the SMP. Functionally, it contains the service creation environment function (SCEF). The SCEP interacts directly with the SMP. j) Service management access point (SMAP) The SMAP provides some selected users, such as service managers or some customers, with access to

41、 the SMP. One possible use of the SMAP is to provide one single point of access for a given user to several SMPs. The SMAP functionally contains a service management access function (SMAF). The SMAP nteracts directly with the SMP. 4 Mapping the distributed functional plane to the physical plane 4.1

42、Mapping of functional entities to physical entities This subclause gives a mapping of functional entities into physical entities, and describes the reference points between the PES. In so doing, an appropriate distribution of functionality is identified, and functional interfaces suitable for standa

43、rdization are highlighted. The PES described in this subclause are for illustrative purposes only, and do not imply the only possible mapping of functionality. This subclause describes a flexible physical architecture made up of several PES. Each physical entity contains one or more functional entit

44、ies, which define its IN functionality. PES included in the physicai architecture shown in Figure 1 are SSP, SCP, SDP, IP, AD, SN, SSCP, SMP, SCEP, and SMAP. Typical scenarios of functional entity mapping to physical entity are shown in Table 1. 4 Recommendation Q.1205 (03/93) CCITT RECMN*Q.L205 93

45、411b259L 05801192 T25 d SMAP To all ISMP h d To other SCPs or SDPs in SCP SCEP Ir, Signalling Network I SN I I L/ a) An SSCP PE includes Bie SCF anci SDF FES as core elements. Tmport agndiing - Management, Provisioning & Control Functiond entities (FES) CCF Cdl control function CCAF Cdl control agen

46、t function SCF Service control function SDF Servicedatafmtion SRF Special Tesource function SSF CeMce switching function SMF CeMce management fuiction SCEF Service creatia enviment function SMAF Service maiagement access function Physicd entities (PES) SSP SeMce switching point SCP Service control p

47、oint SDP Servicedatapoint IP Intelligent peripheral SMP Service management point SCEP Service creaaOn envimment point AD Adjunct SN Servicesnodes SSCP Service switching and control point SMAP Service management Access point FIGW UQ.1205 Scenarios for physical architectures Recommendation Q.1205 (03/

48、93) 5 TABLE UQ.1205 There is no intention that the table should disallow any other combination of functional entities that would result in a physical entity not shown in the table. The above mappings are shown in Figure 1. Each physical entity has certain functional entities mapped into it. As indic

49、ated in the legend of the figure, transport paths, signalling paths (that carry application layer messages), and management, provisioning and control paths are differentiated. 4.2 Intelligent network Recommendations largely focus on the definition and specification of application layer protocol to effect the scope of IN functional relationships. For any given capability set, the appropriate underlying protocol platforms are selected from those that are currently available or planned, selecting and adapting to those whose capabilities best meet the IN signall