ImageVerifierCode 换一换
格式:PDF , 页数:12 ,大小:480.89KB ,
资源ID:800863      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-800863.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ITU-T Q 1215-1995 PHYSICAL PLANE FOR INTELLIGENT NETWORK CS-1 (Study Group 11)《IN分布功能平台结构(第11研究组)12页》.pdf)为本站会员(wealthynice100)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

ITU-T Q 1215-1995 PHYSICAL PLANE FOR INTELLIGENT NETWORK CS-1 (Study Group 11)《IN分布功能平台结构(第11研究组)12页》.pdf

1、ITU-T RECMN*Q.1215 95 W 48b2591 Ob15810 TTB W INTERNATIONAL TELECOMMUNICATION UNION ITU=T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Q.1215 (1 0/95) INTELLIGENT NETWORK PHYSICAL PLANE FOR INTELLIGENT NETWORK CS-1 ITU-T Recommendation Q.1215 (Previously “CCITT Recommendation“) ITU-T RECMN*Q.LZLS

2、 95 4862591 ObL58LL 934 D FOREWORD The ITU-T (Telecommunication Standardization Sector) is a permanent organ of the International Telecommunication Union (ITU). The ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommen- dations on them with a view to standa

3、rdizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the ITU-T Study Groups which, in their turn, produce Recommendations on these topics. The approval of Recommendations by t

4、he Members of the ITU-T is covered by the procedure laid down in WTSC Resolution No. 1 (Helsinki, March 1-12, 1993). ITU-T Recommendation Q.1215 was revised by ITU-T Study Group 11 (1993-1996) and was approved under the WTSC Resolution No. 1 procedure on the 17th of October 1995. NOTE In this Recomm

5、endation, the expression “Administration” is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. O ITU 1996 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, in

6、cluding photocopying and microfilm, without permission in writing from the ITU. ITU-T RECNN*Q.L215 95 = 48b259L Ob35832 870 CONTENTS SUMMARY 1 General . 2 Requirements and assumptions 2.1 Requirements 2.2 Assumptions . 3 Physical Entities (PES) . 4 . Mapping requirements 5 . Mapping the distributed

7、functional plane to the physical plane . Mapping of functional entities to physical entities . Mapping of FE-FE relationships to PE-PE relationships . Selection of underlying protocol platforms 5.1 5.2 5.3 Page 11 1 1 1 1 2 3 4 4 6 6 Recommendation Q.1215 (10/95) i SUMMARY This Recommendation descri

8、bes the physical plane of the IN architecture for CS-1. The physical plane identifies different Physical Entities (PES), the allocation of functional entities to PES, and the interfaces between the PES. The status of the text in this Recommendation is stable and there are no outstanding issues ident

9、ified for further study. Companion Recommendations include the Q. 1200- and Q. 1210-Series of Recommendations, especially that of Recommendation 4.1205, which describes the physical plane for general IN. The revisions that appear in the current text of this Recommendation were applied to make it con

10、sistent with the companion Recommendations. 11 Recommendation Q.1215 (10/95) Recommendation Q.1215 PHYSICAL PLANE FOR INTELLIGENT NETWORK CS-1 (Helsinki, 1993; revised in 1995) 1 General This Recommendation describes the physical plane of the IN architecture for CS-1. General IN physical plane infor

11、ma- tion is contained in Recommendation Q.1205. 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 tha

12、t can be used to design the IN architecture to meet the following main objectives: - service implementation independence; - network implementation independence; - vendor and technology independence. The I. 130 stage 3 service description methodology may be used (which includes the functional specifi

13、cation 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 CS-1 distributed functional plane

14、can be mapped onto the CS-1 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 (i.e. the functional entity is mapped entirely within a single physical entity); duplicate instances of a fu

15、nctional 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 funct

16、ional entities and the standard interfaces; vendors must be able to support mature technologies and new technologies as they become available. 2.2 Assumptions The following assumptions are made for the development of the physical plane architecture: - - the IN conceptual model is used as a tool to d

17、evelop the IN physical architecture; existing and new technologies can be used to develop the physical entities; Recommendation Q.1215 (10/95) 1 ITU-T RECMN*Q.LZLS 95 48b2593 Ob35835 58T M - the specification of functional entities in the distributed functional plane and standard interfaces in the p

18、hysical plane will make the network vendor independent and service independent; - for CS-1, a sufficient number of interfaces will be identified for support of services. Service creation and OAh4 functions will not be addressed. 3 Physical Entities (PES) This clause describes a selection of PES to s

19、upport IN CS-1. That selection is not intended to preclude or disallow the application of any other IN PE to support CS-1. - 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 functionalit

20、y, the SSP allows access to the set of IN capabilities. The SSP contains detection capability to detect requests for IN-based services. It also contains capabilities to communicate with other PE) containing a Service Control Function (SCF), s.uch as a Service Control Point (SCP), and to respond to i

21、nstructions from the other PE. Functional1y;an SSP contains a Call Control Function (CCF), a Service Switching Function (SSF), and, if the SSP is a local exchange, a Call Control Agent Function (CCAF). It also may optionally contain a Service Control Function (SCF), andor a Specialized Resource Func

22、tion (SRF), and/or a Service Data Function (SDF). The SSP may provide IN-based services to users connected to subtending Network Access Points. b) Network Access Point (NAP) An NAP is a PE that includes only the CCAF and CCF functional entities. It may also be present in the network. The NAP support

23、s early and ubiquitous deployment of IN-based services. This NAP cannot communicate with an SCF, but it has the ability to determine when IN processing is required. It must send calls requiring IN processing to an SSP. c) Service Control Point (SCP) The SCP contains the Service Logic Programs (SLPs)

24、 and data that are used to provide IN-based services. The SCP is connected to SSPs by a signalling network. Multiple SCPs may contain the same SLPs and data to improve service reliability and to facilitate load sharing between SCPs. Functionally, an SCP contains a Service Control Function (SCF) and

25、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 be connected to SSPs, and optionally to IPS, through the signalling network. The SCP can also be connect

26、ed to an IP via an SSP relay function. d) Adjunct (AD) The Adjunct PE is functionally equivalent to an SCP (Le. it contains the same 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 r

27、esult in differing performance characteristics for an Adjunct and an SCP. The application layer messages are identical in content to 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. 2 Recommendat

28、ion Q.1215 (10/95) e) Intelligent Peripheral (IP) The IP provides resources such as customized and concatenated voice announcements, voice recognition, and Dual Tone Multi-Frequencies (DTMF) digit collection, and contains switching matrix to connect users to these resources. The IP supports flexible

29、 information interactions between a user and the network. Functionally, the IP contains the Specialized Resource Function (SRF). The IP may directly connect to one or more SSPs, and/or may connect to the signalling network. An SCP or Adjunct can request an SSP to connect a user to a resource located

30、 in an IP that is connected to the SSP from which the service request is detected. An SCP or Adjunct can also request the SSP to connect a user to a resource located in an IP that is connected to another SSP. f Service Node (SN) The SN can control IN-based services and engage in flexible information

31、 interactions with users. The SN communicates directly with one or more SSPs, each with a point-to-point signalling and transport connection. Functionally, the SN contains an SCF, SDF, SRF, and an SSF/CCF. This SSF/CCF is closely coupled to the SCF within the SN, and is not accessible by external SC

32、Fs. In a manner similar to an Adjunct, the SCF in an SN receives 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 u

33、sers in a manner similar to an IP. An SCF can request the SSF to 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. g

34、) 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 same service

35、 capability as an SSP and SCP separately. This node may also contain SRF functional capabilities (i.e. SRF as an optional capability). 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) Service D

36、ata Point (SDP) The SDP contains the customer and network data which is accessed during the execution of a service. Functionally, the SDP contains an SDF. 4 Mapping requirements - physical plane architecture requirements listed in 2.1 should be met; - functional entities should be mapped to physical

37、 entities in a manner which will support the identified benchmark CS-1 services; - functional entity to physical entity mapping must allow efficient implementation in existing physical en ti ties; - functional entity to physical entity mapping must allow for standard communications between network f

38、unctions via service independent interfaces. 3 Recommendation Q.1215 (10/95) ITU-T RECMN*Q.3235 95 m 4862593 Ob15817 352 I PES 5 Mapping the distributed functional plane to the physical plane FES 5.1 Mapping of functional entities to physical entities SSP SCP This subclause gives a mapping of functi

39、onal entities into physical entities for CS-1, and describes the reference points between the PES. In so doing, an appropriate distribution of functionality for CS-1 is identified, and functional interfaces suitable for standardization are highlighted. The PES described in this subclause are for ill

40、ustrative purposes only, and do not imply the only possible mapping of functionality for CS- 1. O C O O - C - C This subclause describes a flexible physical architecture made up of several PES. Each PE contains one or more functional entities, which define its IN functionality. PES included in the p

41、hysical architecture shown in Figure 1 are Service Switching Point (SSP), Network Access Point (NAP), Service Control Point (SCP), Intelligent Peripheral (E), Adjunct (AD), Service Switching and Control Point (SSCP), Service Data Point (SDP), and Service Node (SN). Typic.al scenarios of functional e

42、ntity mapping to physical entity are shown in Table 1. TABLE UQ.1215 Typical scenarios of FE to PE mapping r I SCF I SSFICCF I SDF I SRF C Core O Optional - Not allowed There is no intention that the table should disallow any other combination of functional entities that would result in a PE not sho

43、wn in the table. The above mappings are shown in Figure 1. Each PE has certain functional entities mapped into it. The solid lines on the figure show transport paths that may exist between the PES. and the dotted lines show signalling paths that can cany application layer messages for IN-based servi

44、ces. 4 Recommendation Q.1215 (10195) ITU-T RECFlN*Q.1215 95 m 4862593 Ob15818 299 m : ! I SDP I /- -.-e- - TO other SCPs and/or .- - -+ SDPS in this or another network .*- Interfaces: e-.- SCP-SSP -. AD-SSP IP-SSP SN-SSP SCP-IP AD-IP SCP-SDP .e* SS No. 7 Network ._._.- Ti 143320-9zdoi a) An SSCP PE

45、additionally includes the SCF and SDF FES as core elements. Transport . Signalling r- ) Optional FE *. -*-C.-* Physical entities (PES) AD Adjunct IP Intelligent Peripheral SSP SeMceSwilchin Point SCP serme control #oint SN SeMcesNode NAP Network Access Point SDP Service Data Point SSCP Service SwiQh

46、ing and Contrc -. Functional entities (FES) CCF Cali Control Function CCAF Call Control Agent Function SCF Senice Control Function SDF Senice Data Function SRF Special Resource Function SSF SeMce Switching Function Poir FIGURE UQ.1215 Scenarios for physical architectures Recommendation Q.1215 (10/95

47、) 5 - ITU-T RECMN*d=1215 95 4862591 Ob15819 125 FE-FE SSF-SCF SCF-SDF SCF-SRF 5.2 Mapping of FE-FE relationships to PE-PE relationships PEPE SSP-SCP SSP-AD SSP-SN SSP-SCP SCP-SDP SCP-IP SCP-SSP-IP AD-IP The FE-FE interfaces that fail within the scope of CS-1 are: 1) SSF-SCF; 2) SCF-SDF; and 3) SCF-S

48、RF. A mapping to the PE-PE interfaces is provided in Table 2. Table 2 is not meant to be an exhaustive list of ail possible PE-PE relationships that may be covered by the CS-1 Recommendations. TABLE 2/Q.1215 FE-FE relationships to PE-PE relationships 5.3 Selection of underlying protocol platforms Th

49、is subclause describes the candidate interfaces for CS-1 between the elements of the physical architecture. The interfaces are identified below. - SCP-SSP; - AD-SSP; - IP-SSP: - SN-SSP; - SCP-IP; - AD-Rand - SCP-SDP. Existing lower-layer protocols are proposed for these candidate interfaces to cany the application layer messages required by IN-based services. As such, the focus of the standardization effort for CS-1 is on the application layer protocols. At the application layer, the message sent that the different

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1